Content router processing

ABSTRACT

A method, apparatus, and system for routing changes to information between a plurality of content nodes and a command memory of a content router. Content nodes may be user devices (such as mobile phones) and user accounts (such as email accounts). Content nodes may hold one or more content types such as email, contacts, tasks, events and library items. A command memory centralizes conflict detection, resolution and error handling within a content routing system.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation-in-part of and claims benefit topreviously filed U.S. patent application Ser. No. 11/182,287, filed Jul.14, 2005, entitled CONTENT ROUTER, to Torsten SCHULZ et al., and ishereby incorporated by reference as if fully set forth herein. Thisapplication is further related to co-filed U.S. patent application Ser.No. ______(Attorney Docket No. 324212011000), filed Oct. 31, 2005,entitled CONTENT ROUTER CORE VARIANTS, to B. Ebbesen et al., and ishereby incorporated by reference as if fully set forth herein.

BACKGROUND

1. Field

The present invention relates generally to maintaining user devices andaccounts, and more particularly to synchronizing information accessiblefrom multiple devices and networked accounts.

2. Description of Related Art

Known routers and synchronization systems do not analyze the payloaddata received from one node to determine whether or not to forward allor part of the data to a second node. For example, a router uses anaddress it receives and a routing table to determine which destinationnodes will receive a copy of the incoming packet. Known routersdetermine routing based on the address of packet. Additionally, knownrouters do not contain long term memory to hold packets. Thus, a packetwill not be received by the second node unless the first node sends thepacket to the router while the second node is also connected to therouter.

A synchronization system holds a master copy of a set of records it ismirroring on one or more handheld devices. After a change occurs on onedevice and that device forwards a changed recorded to thesynchronization system, the synchronization system updates its mastercopy, which is then available to other devices when they synchronize tothe system. Known synchronization systems must keep a master copy of allsynchronized records. For example, a hand held organizer may operatewith a synchronization tool on a PC. Both the organizer and PC maintaina master copy of all records. Thus, a master copy may be maintained atmultiple locations. Additionally, if a synchronization system is to workwith devices not simultaneously connected to the synchronization system,the synchronization system will need to keep a copy of each new record.If a record represents an audio file or an image file, thesynchronization system may need a substantial amount of storage.

Hence, an improved system for synchronizing destinations of contentwould be advantageous and in particular a system allowing increasedflexibility, reduced complexity and/or improved performance would alsobe advantageous.

BRIEF SUMMARY

In accordance with one aspect of the invention, there is provided acontent routing system for routing changes to information between aplurality of content nodes and a command memory, the content routingsystem comprising: store and forward logic including: processing logicfor: processing an incoming command from a first content node; selectinga set of destination content nodes based on a content type of theincoming command and one or more routing parameters; and generating anoutgoing command for each of the selected destination content nodes; andcommand memory, coupled to the processing logic, for holding theincoming command and the set of outgoing commands; and a connected dataset configuration, coupled to the processing logic, for holding the oneor more routing parameters.

Some embodiments include a gateway for translating between the firstprotocol and a common protocol; and a protocol adapter for translatingbetween the common protocol to the command protocol. Some embodimentsinclude a command memory having an incoming queue for holding theincoming command and an outgoing queue for holding the set of outgoingcommands. Some embodiments include a database for holding the incomingcommand and the set of outgoing commands, wherein each command has anattribute identifying a state of the command. Some embodiments includean outgoing in-transit queue state. Some embodiments include an incomingin-transit queue state.

In accordance with another aspect of the invention, there is provided acontent routing system comprising: store and forward logic includinglogic for selecting destination content nodes based on a content type ofan incoming command and one or more routing parameters; modifying theincoming command to generate at least one outgoing command, wherein eachoutgoing command corresponds to a selected content node; and a connecteddata set configuration for holding the one or more routing parameters.

In some examples the data modulation logic may further include at leastone data module operable to modify a data field of the incoming commanddata structure. The incoming command may include an XML-tree datastructure schema, for example, and the data modulation logic may modifya particular node of the XML-tree data structure. In some examples, thedata modulation logic may operate to divide a first incoming commandassociated with a first a content entry into multiple outgoing commandsassociated with second multiple content entries. Additionally, the datamodulation logic may operate to merge multiple first incoming commandsassociated with first content entries into a relatively smaller numberof second commands associated with second content entries.

In some examples, the content routing system may further include dataconsolidation logic operable to identify potential duplicate contententries within a connected community of content nodes based on comparinga hash-value of the incoming command to a list of hash-values. In oneexample, the hash-value is determined from less than all of the incomingcommand or content, e.g., a predefined significant property of thecontent entry.

In accordance with another aspect of the invention, there is provided amethod of routing changes to information between a plurality of contentnodes and a command memory, the method including receiving an incomingcommand from a first content node; storing the incoming command in acommand memory associated with the first content node; selecting a setof destination content nodes based on a content type of the incomingcommand and a routing parameter associated with the destination contentnode and the content type; and modulating the incoming command based oncapabilities of the destination content node, wherein the modulatingcomprises targeting a specific field of the incoming command datastructure with a data module operable to modify the data structure forgeneration of an outgoing command.

In accordance with another aspect of the invention, there is provided acomputer program product comprising program code for use in a contentrouting system including processing logic and a command memory, thecontent routing system for routing changes to information between aplurality of content nodes and the command memory, the computer programproduct comprising program code for receiving an incoming command from afirst content node; program code for selecting a set of destinationcontent nodes based on a content type of the incoming command and arouting parameter associated with the destination content node and thecontent type; program code for modulating the incoming command based oncapabilities of the destination content node, wherein the program codefor modulating comprises data modulation logic operable to modify thedata structure of the incoming command for generation of an outgoingcommand; and program code for generating the outgoing command.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects and examples will be described, by way of example only,with reference to the drawings, in which:

FIGS. 1A and 1B show information distribution and synchronizationsystems.

FIG. 2 illustrates a content router coupled to multiple content nodesvia a network according to embodiments of the present invention.

FIG. 3 shows a path of propagating a change in one content node to aselected set of content nodes via a content router according toembodiments of the present invention.

FIG. 4 shows a user's connected email accounts and includes an examplescreenshot according to embodiments of the present invention.

FIGS. 5 and 6 illustrate the connections to and processing performed bystore and forward logic according to embodiments of the presentinvention.

FIGS. 7A and 7B illustrate store and forward logic coupled to arepository according to embodiments of the present invention.

FIGS. 8A and 8B illustrate a process of stripping a separable segment ofan exemplary email then requesting the stripped segment from a source ofthe email according to embodiments of the present invention.

FIGS. 9A to 9F illustrate various exemplary structures of store andforward logic and data paths between processing logic and content nodesaccording to embodiments of the present invention.

FIGS. 10A to 10D show a PUT-GET-ACK procedure from a point of view acontent node and a content router according to embodiments of thepresent invention.

FIG. 11 illustrates representation of a structure of a connected dataset configuration according to embodiments of the present invention.

FIGS. 12A to 12E illustrate external and internal logic, which may beused to interface a content router to user devices and user accountsaccording to embodiments of the present invention.

FIGS. 13 and 14A to 14I show structures of various commands according toembodiments of the present invention.

FIGS. 15A to 15C illustrate sequence diagrams showing signaling betweena user device and store and forward logic according to embodiments ofthe present invention.

FIGS. 16A to 16D illustrate sequence diagrams showing signaling betweena user account and store and forward logic according to embodiments ofthe present invention.

FIGS. 17A-17C illustrate exemplary instructions according to one aspectof the present invention.

FIGS. 18A-18E illustrate exemplary data structures according to severalaspects of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, reference is made to the accompanyingdrawings which illustrate several embodiments of the present invention.It is understood that other embodiments may be utilized and mechanical,compositional, structural, electrical, and operational changes may bemade without departing from the spirit and scope of the presentdisclosure. The following detailed description is not to be taken in alimiting sense, and the scope of the embodiments of the presentinvention is defined only by the claims of the issued patent.

Some portions of the detailed description which follows are presented interms of procedures, steps, logic blocks, processing, and other symbolicrepresentations of operations on data bits that can be performed oncomputer memory. A procedure, computer executed step, logic block,process, etc., are here conceived to be a self-consistent sequence ofsteps or instructions leading to a desired result. The steps are thoseutilizing physical manipulations of physical quantities. Thesequantities can take the form of electrical, magnetic, or radio signalscapable of being stored, transferred, combined, compared, and otherwisemanipulated in a computer system. These signals may be referred to attimes as bits, values, elements, symbols, characters, terms, numbers, orthe like. Each step may be performed by hardware, software, firmware, orcombinations thereof.

FIG. 1A shows a routing system. A router 100 includes a routing module101 and a routing table 102 used to route packets 120. The router 100uses both address information appended to the packet 120 and the routingtable 102 to determine which data sinks 140-1 to 140-3 will receive aforwarded copy of an incoming packet 120. The router 100 forwards thepacket 120 as packets 130-1 to 130-3. Known routers do not determinerouting based on the type of content included in an incoming packet 120,but rather based on the address information appended to the packet 120.

FIG. 1B shows a synchronization system including a PC 150 and multipledata holders 160. A data holder 160 may be a hand held organizerconnected to the PC 150 via a cradle. A user may change information,such as entering a new contact, into a first data holder 160-1.Periodically, the user connects the data holder 160 to the PC 150 andsynchronizes each data holder 160 using a CPU 151 of the PC 150. Thefirst data holder 160-1 exchanges data 170-1 with the CPU 151. The CPU151 saves any updated and new information as data 171. The PC 150accumulates a persistent copy 152 of data 171 synchronized through it.When a second data holder 160-2 synchronizes with the PC 150, the CPU151 updates the second data holder 160-2 with the information saved fromthe first data holder 160-1. Even after both data holders 160-1 and160-2 have been synchronized, the synchronization system preserves acopy of the changed information as persistent copy 152 even though thechanged information is no longer needed for synchronization. Knownsynchronization systems keep a complete persistent copy 152 of datasynchronized through the synchronization system.

FIG. 2 illustrates a content router 200 coupled to multiple contentnodes 300-1 to 300-3 via a network 10 according to embodiments of thepresent invention. The content router 200 facilitates synchronization ofsimilar and dissimilar content nodes 300-1 to 300-3 attachable to thenetwork 10. The content router 200 may be a single network componentimplemented in hardware and/or software. Alternatively, the contentrouter 200 may be a system of networked components. The content router200 uses commands 400-1 to 400-3 sent across the network 10 tocommunicate information. The network 10 connects each content node 300-1to 300-3 with the content router 200 using commands 400. The network 10may be a conglomeration of disparate wired and/or wireless network suchas interconnected intranets, the Internet and mobile radio networks.Alternatively, the network 10 may be a single network. Additionally, thecontent router 200 may bridge two or more separate networks.

A command 400-1 may be communicated within a message from a content node300-1. The message may be encoded as a sequence of bits using a protocolavailable to the content node 300-1. A message may contain a segment ofa command, in which case multiple messages may be aggregated to form acomplete command. Alternatively, a message may contain multiplecommands. In some protocols used by a content node 300, one or moremessages may represent one or more commands. The content router 200 maytranslate between the message protocol used by a content node 300 and acommand structure or protocol used internally in the content router 200.

From a content node 300, a user may use commands to enter, store,access, update, modify, and/or delete content or metadata (i.e.,information about content). Content may have one of various contenttypes, such as contacts, calendar events, tasks, emails and/or libraryitems. Furthermore, content may have a personal information management(PIM) content type, which may include a contact, calendar event or atask. A library item includes a media object such as a photo image, anaudio file, a video clip, a movie or a document, or may be a group ofsuch items such as album of photos or collection of home movies.Metadata includes information about such content.

A content node 300 may be a user's account on a server. Such a contentnode 300 may have access to content of a single content type. Forexample, a user account may be a personal email account on an emailserver (e.g., Yahoo!® Mail), a family photo album account on a photoserver (e.g., Yahoo!® Photos), a PIM account on a PIM server (e.g.,Yahoo!® Address book or Yahoo!® Notepad), or a music library account ona multimedia library server (e.g., Yahoo!® Music). Furthermore, acontent node 300 may be a user account having access to two or morecontent types. For example, a user account may have access to email, PIMinformation, calendar information and a notepad, such as with a Yahoo!®user account.

A content node 300 may be a user device. Such a user device may be awired device, such as a home personal computer, an office PC, a digitalcamera or a set-top box, or may be a wireless device, such as a mobilephone, a laptop, handheld PC, or a digital camera with wirelesscapabilities. Some devices may have both wired and wirelesscapabilities, while other devices may have either wired or wirelesscapabilities. Some user devices may have access to a single contenttype. Other user devices have access to two or more content types.

A content node 300 may be a user device that organizes information,including PIM devices such as a Blackberry® or a Treo®, or morededicated mobile phones that provide more limited information managementservices. Information management services may include, for example, PIMservices such as calendar, address book, tasks, and notes. A calendartypically maintains time-related organizational attributes such asevents (e.g., meetings, birthdays, holidays) related to correspondingdate and time ranges. An address book typically maintains organizationalattributes related to a person (e.g., a legal “person” such as a humanor business entity, or even a pet), a place (e.g., the person'saddress), or other contact information attributes (e.g., telephonenumbers).

FIG. 3 shows a path of propagating a change in one content node 300-1 toa selected set of content nodes 300 via a content router 200 accordingto embodiments of the present invention. A set of content nodes 300 mayinclude a null set of content nodes, a single content node, a subset ofone or more content nodes, or all content nodes. A content node 300 mayact as a source of data (data source), a sink of data (data sink), or acombination of both. In this case, content node 300-1 acts as a datasource while content nodes 300-2, 300-3, 300-6 and 300-8 act as datasinks. A change to a content node 300-1 may represent one of a number ofevents including an addition, modification or deletion of content ormetadata.

As shown, content node 300-1 acts as a source of content or metadata.The content node 300-1 may generate a command 400-1 including changedcontent, or a metadata indication of the change to content, which may becommunicated to the content router 200. The content node 300-1 may pushthe command 400-1 to the content router 200 or it may be polled by thecontent router 200 for the command 400-1.

The content router 200 examines the contents of the command 400-1. Basedon the contents of an incoming command 400-1, the content router 200selects which of the possible content nodes 300-2 to 300-8 will beinformed of the change. In this example, the content router 200 selectscontent nodes 300-2, 300-3, 300-6 and 300-8, then transforms theincoming command 400-1 into outgoing commands 400-2, 400-3, 400-6 and400-8 to distribute an indication of the change. The outgoing commands400-2, 400-3, 400-6 and 400-8 may or may not include the same contentsas the incoming command 400-1. Additionally, the content router 200 doesnot keep a persistent copy of all content synchronized through it.

A content node 300-1 may be a user device (such as a PIM device) or auser account (such as a Yahoo! account) that contains one or moredatabases of content and/or metadata. For example, if the content node300-1 includes an address book, the change may be a new, modified, ordeleted contact. If the content node 300-1 includes a calendar, thechange may be a new, modified, or deleted event, such as an appointment.If the content node 300-1 includes a task list, the change may be a new,modified, or deleted task. Similarly, if the content node 300-1 includesa note pad, the change may be a new, modified, or deleted note. Thechange may also be an addition, modification or deletion of a collectionof information, such as a list of watched stocks, a list of bookmarkedweb pages, or a configuration of a home page.

If the content node 300-1 is an email account, the change may be thatthe email account has received new content, such as an incoming emailmessage from the Internet, or has deleted content, such as deleting anexisting email. The user may have updated metadata, such as changing amessage state from unread to read, marking a message as unread, orsetting an importance level. Similarly, if the content node 300-1 is amobile phone, the change may be that it received new content, such as anew pager message or a new SMS message from a wireless network, or thatthe user has deleted content, such as deleting a message.

Furthermore, if the content node 300-1 is a media library, the changemay indicate that a user has added, modified or deleted a media object,such as a photo image, an audio file, a video clip, a movie or adocument, or may be a group of such items such as an album of photos orcollection of home movies. For example, the change may indicate that auser has added a caption to a photo image, or has loaded a new song.Media objects are further described in related U.S. application Ser. No.11/129,697, filed on May 13, 2005 and titled MEDIA OBJECT ORGANIZATIONACROSS INFORMATION MANAGEMENT SERVICES by inventors Marco BOERRIES etal., and incorporated by reference herein.

In describing a change, a content node 300-1 may send the actual new ormodified content. In some embodiments, a content node 300-1 may insteadsend metadata. Such metadata may include characteristics of the changedcontent, a transformed copy of the changed content, and/or a reference,such as hyperlink or address pointer, to the content in memory. Sendinga reference instead of the actual content allows a receiving contentnode 300-2 to access content from a sending content node 300-1 withoutrequiring the content itself to pass through the content router 200.

A content router 200 may facilitate routing email among severalemail-capable content nodes 300, such as a user device or a useraccount. Email received at a user's first email account, e.g., apersonal email account, may be forwarded via the content router 200 tothe user's second account, e.g., a work email account on a secondcontent node. Similarly, email received at the user's second emailaccount may be forwarded through the content router 200 to the user'sfirst email account. The user may also add a third email account, e.g.,a Yahoo!® email account, and configure the content router 200 to routeemail messages received from the Internet at the third account to thefirst and second accounts.

FIG. 4 shows a user's connected email accounts 320-1 to 320-3, andincludes an example screenshot 20 according to embodiments of thepresent invention. Some content nodes 320, such as an Outlook account,allow a user to set up multiple email boxes or folders. Shown are twoemail accounts 320-1 and 320-2 with a connected inbox and one emailaccount 320-3 without a connected inbox. Connected email accounts mayreport information to the content router 200 and may receive informationfrom the content router 200.

For example, a content node (320-1, 320-2 or 320-3) may report a newincoming email to the content router 200 in a command (31, 32 or 33,respectively). In response to each incoming command (31, 32 or 33), thecontent router 200 selects a set of destination content node (e.g.,320-1 and 320-2, respectively) and forms an outgoing command (34 and 35)destined for an inbox of each selected content node (320-1 and 320-2,respectively).

The screenshot 20 from a user's personal email account 320-1 shows aninbox 21 for holding email messages received directly from the Internetwithout passing through the content router 200, and a connected inbox 22for holding email messages received from the content router 200. Theconnected inbox 22 contains emails merged from each of the user'sconnected email accounts 320-1 to 320-3. By viewing the connected inbox22, a user may quickly see in one folder all email destined for theuser's multiple connected email accounts. A connected inbox 22 may thusbe viewed as a window to all emails sent to a user across the user'sseveral connected email accounts.

A user may also configure an email account to include a separate folderor inbox for each content node 300 that has email capabilities. Here,the screenshot 20 shows an inbox 23 for emails from a personal emailcontent node 320-1, an inbox 24 for email from a work email content node320-2, and an inbox 25 for email from a Yahoo!g email content node320-3. Using separate folders allows a user to manage individual emailaccounts from one content node, for example, user account 320-1.

FIGS. 5 and 6 illustrate connections with and processing performed bystore and forward logic 210 according to embodiments of the presentinvention. The store and forward logic 210 allows multiple connectedcontent nodes 300 to communicate changes to information on one contentnode 300 to other content nodes 300 through the content router 200without requiring each content node 300 to be simultaneously coupled tothe content router 200. The store and forward logic 210 may be decoupledfrom content node specifics. That is, the store and forward logic 210may treat each content node similarly, regardless of whether a contentnode is a user device or a user account, or whether the content nodeoperates as a client or as a server. Additionally, the store and forwardlogic 210 may move the task of conflict detection away from the contentnodes and centralize the task of conflict detection and resolution towithin the store and forward logic 210.

The store and forward logic 210 may be implemented in hardware,executable code or a combination of both. The store and forward logic210 may include VLSI and/or FPGA hardware. The store and forward logic210 may include a stand alone server or a network of servers. The storeand forward logic 210 may be implemented with a general purpose centralprocessing unit (CPU) or may be implemented with a reduced instructionset computer (RISC). The store and forward logic 210 may include on-chipor off-chip memory such as RAM, PROM, EPROM, E²PROM and/or the like. Thestore and forward logic 210 may also include magnetic memory, such as ahard disk drive, and may include optical memory. The executable code maybe derived from scripts, software, firmware and/or machine code.

The content router 200 of FIG. 5 includes store and forward logic 210coupled to a connected data set configuration 500, and a repository 600.The store and forward logic 210 may be coupled to associated contentnodes 300-1 to 300-4. FIG. 6 shows a sequence of events triggered in thestore and forward logic 210 by an incoming command beginning at 1000.Those actions include processing an incoming command at 1001, selectingoutgoing content nodes at 1002, generating outgoing commands at 1003,processing outgoing commands at 1004, and sending the processed outgoingcommands at 1005. Whether a command is an incoming or outgoing is viewedfrom the perspective of the store and forward logic 210.

At 1000, the sequence of events begins when a content node 300-1, havinga change to report, sends a new command 400-1 to the store and forwardlogic 210. A content node 300-1 does not send the change (such as acommand to add an included new email message) to other content nodes.Rather, the content node 300-1 sends the change to the store and forwardlogic 210, which may or may not create a set of outgoing command to sendthe new email message or parts of the new email message to acorresponding set of content nodes.

At 1001, the store and forward logic 210 processes the incoming command400-1 from the content node 300-1. Processing incoming commands 400-1may include transforming commands based on limitations or specializedcapabilities of the originating content node 300-1. When transformingcommands, the store and forward logic 210 may use the repository 600,which may hold one or more separable segments of a command, and theconnected data set configuration 500, which contains transforming rulesused when processing a command. Transforming incoming and outgoingcommands is further described with reference to FIGS. 7A, 7B, 8A and 8B.

Processing an incoming command 400-1 may also include detection andresolution of a conflict between the incoming command 400-1 and acommand pending in the store and forward logic 210. The store andforward logic 210 may hold multiple pending commands in memory waitingto be acted upon. A pending command may be a previously received andprocessed incoming command from a particular content node 300 that iswaiting for further processing by the store and forward logic 210.Additionally, a pending command may be a command generated by the storeand forward logic 210 in response to an incoming command. Thesegenerated commands are waiting to be transmitted to a particular contentnode 300 as an outgoing command (e.g., 400-2 or 400-4).

Conflict resolution may include discarding the new command 400-1,deleting a pending command, and/or aggregating of the new command 400-1with a pending command. A conflict may arise if a new incoming command400-1 conflicts with a previously received incoming command pendingexecution. For example, a previously received incoming command may be acommand to add a new email received from the Internet by the contentnode 300-1. A subsequent incoming command may be to delete that sameemail, for example, if a user has deleted the email from its inbox oncontent node 300-1. If the command to add the new email is still pendingin the store and forward logic 210 when the subsequent command to deletethe same email is received, a conflict exists. In this case, theconflict is resolved by discarding both commands. Alternatively, if thesubsequent incoming command was instead to add the same new email, thestore and forward logic 210 detects the duplicate commands and resolvesthe conflict by discarding one of the duplicate commands.

A conflict may also arise if a new incoming command 400-1 conflicts witha command previously generated as an outgoing command for a particularcontent node 300. For example, the store and forward logic 210 may holda pending outgoing command to update a contact in an address book. A newincoming command may be to delete that same contact altogether. Thestore and forward logic 210 detects and resolves this conflict byremoving the pending outgoing command (update-contact) and saving thenew incoming command (delete-contact). The new incoming command willeventually be processed and the delete-contact action will be propagatedas an outgoing command to other connected content nodes 300.

The store and forward logic 210 may also aggregate an incoming command400-1 with a pending command for a content node 300. For example, apreviously received incoming command 400-1 may be to add a new task to atask list. A subsequent incoming command 400-1 may be to modify thistask in some way. The store and forward logic 210 detects and resolvesthis conflict by incorporating the modifications from the subsequentincoming command (modify task) into the previous incoming command(add-task). The resulting aggregated command may be an add of themodified task. The resulting aggregated command may replace the previousincoming command. Alternatively, the previous incoming command may bediscarded and the resulting aggregated command may be saved as a newincoming command. Detection and resolution of conflicts are furtherdescribed with reference to FIGS. 9A-9C and 10A-10D.

At 1002, the store and forward logic 210 selects a set of outgoingcontent nodes, here content nodes 300-2 and 300-4. When selectingoutgoing content nodes, the store and forward logic 210 may again usethe connected data set configuration 500, which also contains routingparameters used in routing rules. Routing rules and the connected dataset configuration 500 are further described with reference to FIG. 11.

At 1003, the store and forward logic 210 generates an outgoing command400-2 and 400-4 for each selected content node 300-2 and 300-4,respectively. Depending on capabilities and a configuration of theselected content node, the store and forward logic 210 may alter theprocessed incoming command to suit the limitations or requirements ofthe selected destination content node. For example, depending uponlimitations of a destination content node, the store and forward logic210 may use a repository 600 to hold a separable segment of an incomingcommand 400-1 and either modify or eliminate that segment from theoutgoing command. Conversely, the content router 200 may insertadditional segments of information into an outgoing command.

The content router 200 may alter a command based on user defined rules,system defined rules, or known content node limitations. The contentrouter 200 may modify a command based on information found within theincoming command 400-1. The content router 200 may append metadata, suchas location, time or other information accessible from a user's accountor device, to the outgoing command. The content router 200 may hold arecord of how a command is modified so that it may reverse themodification if a related command is returned. In some cases, thecontent router 200 passes a command through without modification.

At 1004, the store and forward logic 210 processes the outgoingcommands. As with incoming commands at 1001, the store and forward logic210 similarly performs conflict detection and resolution between a newoutgoing command and pending incoming and outgoing commands.

At 1005, the store and forward logic 210 sends the outgoing commands 400to the respective content nodes 300. Sending an outgoing command 400 mayinclude signalling a notification to the content node 300. Unlike arequest (in a request-response protocol), a notification is a signalwhere a sender does not expect a response or an acknowledgement that thenotification was received. In this respect, a notification is selfcontained in that it is complete once sent. Additionally, a notificationmay be implemented in software (e.g., a semaphore, flag or softwaresignal instruction) and/or hardware (e.g., a hardware line or aregister). The notification may include a content type of the outgoingcommand 400. If the content node is connected to the network 10 with anIP address, the store and forward logic 210 may send an HTTP command tonotify the content node that an outgoing command is pending. If thecontent node is a mobile phone having SMS capabilities, the store andforward logic 210 may send a notification via an SMS message.

A content node 300-1 may send content having one or more segments in acommand 400-1. To minimize the amount of data flowing out of the contentrouter 200, the store and forward logic 210 may replace one or moresegments of a command with a corresponding one or more references thatprovide a link back to the original content rather than forwarding theoriginal segments themselves. Alternatively, the content node 300-1 mayinclude one or more references to a source of the content rather thanincluding the content itself.

A content node 300-4 receiving the reference to content (e.g., areference to a new photo residing on content node 300-1) may instigate apeer-to-peer transfer 450 to retrieve the content from content node300-1. In this manner, the content router 200 may facilitate a transferof content between two content nodes in the form of a peer-to-peertransfer 450 while both content nodes are simultaneously connected tothe network 10.

Due to limitations or requirements of a content node, the store andforward logic 210 may adapt the command by modifying, replacing oreliminating a separable segment of the command before sending it to acontent node. For example, some content nodes may be unable to process,use or store some segments of a command. In some embodiments, the storeand forward logic 210 may accommodate these content nodes that havelimited capabilities using one of three methods described below, some ofwhich use a repository. The store and forward logic 210 may also usesthese methods for other reasons, such as memory limitations in a contentnode or bandwidth restrictions between the store and forward logic 210and the content node, even though the content node is capable ofhandling the entire incoming command.

In some cases, the content router 200 is configured to poll a contentnode 300 for new commands. A content router 200 may periodically poll acontent node 300 to determine whether any changes have occurred. Theperiod of polling may be based on the type or expected cost of aconnection to the network. For example, if a content node 300 is amobile phone connected to the network via an SMS connection, polling maytake place every 24 hours. If the mobile phone connected to the networkvia a GPRS data network connection, polling may occur every 20 minutes.If the mobile phone is placed in a docking station with a wiredconnection to the Internet, polling may occur every few seconds to everyfew minutes.

In some cases, notifications from the store and forward logic 210 to acontent node 300 may be blocked because the content node 300 is behind afirewall. To receive commands, the content node 300 may be configured topoll the content router 200. When the content node 300 polls for pendingoutgoing commands 400, the store and forward logic 210 may reply withone command or a batch of commands for the content node 300 to process.The structure of commands 400 is further described with reference toFIGS. 13 and 14A-14I. The notification and exchange of commands betweenthe store and forward logic 210 is further described with reference toFIGS. 15A-15C and 16A-16D.

According to a first method, the store and forward logic 210 mayaccommodate a limited capability content node by stripping incompatibleor undesired segments from the payload and save the stripped segments ina repository 600. Thus, the repository 600 may hold segments ofcommands, which will be available for future use. If those segments arelater needed, the store and forward logic 210 may access them from therepository 600. This method is described below with reference to FIGS.7A and 7B.

FIGS. 7A and 7B illustrate store and forward logic 210 coupled to arepository 600 according to embodiments of the present invention. Due tolimitations or requirements of a content node 300, the store and forwardlogic 210 may adapt the command by eliminating a segment of the commandbefore sending it to the content node 300. Before adapting the command,the store and forward logic 210 may preserve a copy of the unmodifiedsegment or the entire command in the repository 600. Thus, therepository 600 may hold one or more segments of commands, which will beavailable for future use. In accordance with other embodiments, asegment may also be available to remove segments, such as a file in anemail, from a command. For example, a file may be removed for anincoming command as described below with reference to FIG. 8A.Alternatively, a file may be removed for an incoming command asdescribed below with reference to a file relay server and FIG. 12E.

FIG. 7A shows store and forward logic 210 using a repository 600 to holda separable segment of an incoming command 400-1 from a first contentnode 300-1. When commands contain content that is separable anddistinct, the separable content may be parsed away from the command orpiecewise modified. For example, a contact may include a full name(first segment 401), a home phone number (second segment 402) and a workphone number (third segment 403). Each of these segments may beseparable and distinct. That is, one or more of these segments may beremoved and/or modified and/or combined, thereby forming a modifiedcommand. For example, if a particular content node, such as a mobilephone, has a limitation that it can only handle a single phone number,the store and forward logic 210 may remove the work phone number (third)from an incoming command when preparing the corresponding outgoingcommand. The store and forward logic 210 may also place the work phonenumber in a repository 600 for future use.

As another example, an incoming command may include content such as anew email message having an email body and an attached file. Theattached file is separable and distinct from the email body. The storeand forward logic 210 may generate an outgoing command 400-2 to add thenew email to a second content node 300-2. The outgoing command 400-2 tothe second content node 300-2 may include the email body but only areference to the file.

As shown, an incoming command 400-1 is forwarded in part as an abridgedoutgoing command 400-2 to a second content node 300-2. The incomingcommand 400-1 includes an exemplary payload 441 containing threesegments of content and/or metadata 401, 402 and 403. The store andforward logic 210 stores a copy of the third segment 403 in therepository 600 and also prepares an outgoing command 400-2 with apayload 451 containing the first segment 401 and the second segment 402,but leaving off the third segment 403. The content router 200 may leaveoff the third segment 403, for example, due to a limitation of thedestination content node 300-2. Such a limitation may include thecontent node 300-2 having a limited amount of allocated storagecapacity, or a general transforming rule that removes all attachmentsthat are in a predetermined format.

As another example, a user may add a new contact to a content node300-1. The content node 300-1 sends an add contact command 440containing a payload 441, which represents the contact created at thecontent node 300-1. The payload 441 may contain three segments 401 to403 of information. The first segment 401 may be a structure holding afirst and last name. The second segment 402 may be a phone number. Thethird segment 403 may be a hyperlink to a webpage. If a destinationcontent node 300-2 is incapable of receiving a hyperlink, then the storeand forward logic 210 may strip off the third segment 403 containing thehyperlink. Therefore, the payload 451 sent from the store and forwardlogic 210 may be different from the payload 441 received by the storeand forward logic 210. The store and forward logic 210 stores the thirdsegment 403 in the repository 600 for possible future use. For example,the store and forward logic 210 may access the repository 600 after auser changes a segment of the payload 451 and before the store andforward logic 210 forwards the change to the first content node 300-1,as discussed below.

FIG. 7B shows store and forward logic 210 accessing segments from therepository 600 in response to an incoming command 400-2A, which containsthe original first segment 401 and the updated second segment 402A, fromthe second content node 300-2. The second segment 402 may have beenupdated as the result of a user modifying the segment, such as an emailattachment, at content node 300-2. When the store and forward logic 210processes the incoming command 400-2A from content node 300-2, itdetermines whether any segments previously associated with payload 451and now associated with payload 451A are held in the repository 600. Thestore and forward logic 210 determines that the third segment 403 waspreviously associated with payload 451, and merges the third segment 403from the repository 600 with the payload 451A containing the originalfirst segment 401 and an updated second segment 402A to create a fulldata structure. If content node 300-1 is configured to process thecontent held in each segment 401 to 403, the store and forward logic 210prepares a payload 441A containing the first segment 401, the updatedsecond segment 402A, and the reattached third segment 403.

According to a second method, the store and forward logic 210 mayaccommodate a limited capability content node 300-2 by modifying anincompatible or undesired segment from the payload 441. The store andforward logic 210 may save this segment in the repository 600 if it maybe needed in the future. This second method is similar to the firstmethod except that, in the second method, the segment stripped in thefirst method is instead modified and sent to the content node. If in thefuture, the limited capability content node returns the modified segmentin a command, the store and forward logic 210 may replace this returnedsegment with the original segment from the repository 600 before thestore and forward logic 210 forwards the command to other content nodes.

For example, if a command 400-1 arrives from the first content node300-1 including a first name string and a second name string, but thesecond content node 300-2 is only able to handle a single-string name,the store and forward logic 210 may replace the two string structurewith a single string structure containing a concatenated first and lastname in the single string structure. The store and forward logic 210 maystore the structure including the first name string and the second namestring in the repository 600. If that content is later sent (either in amodified or unmodified form) from the second content node 300-2 and adestination content node can handle two-string names, the store andforward logic 210 may replace the concatenated string in the incomingcommand from the second content node 300-2 with the copy of the twostring structure from the repository 600. In this way, missing contentfrom one limited-ability content node 300-2 may be restored before it isforwarded to other content nodes.

Instead of using the repository 600 to preserve an original segment ofcontent that was stripped or modified, store and forward logic 210 mayretrieve the original segment from its source content node or fromstorage referenced by the source content node.

In one example, the content router 200 includes a data modulationcomponent operable to manipulate or modify content and/or metadata of apayload, e.g., segments 401, 402, 403 as shown and described withrespect to FIGS. 7A and 7B. The data modulation component may includelogic within store and forward logic 210 of the content router 200 (see,e.g., FIG. 5). The data modulation component may comprise datamodulation logic including one or more data modules operable to targetdata within a data structure of the payload (e.g., which may bestructured as an eXtensible Markup Language (XML)-tree data structureschema) and perform actions on portions of the data (e.g.,modifying/deleting one or more segments 401, 402, 403) to carry outvarious functions described herein. In one example, multiple datamodules for targeting and acting on data within the data structure ofthe payloads are configured to carry out various modulations for routingto one or more content nodes, e.g., 300-1, 300-2, and so on.

In one illustrative example, payloads (e.g., 441A, 451A) associated withincoming and outgoing commands are structured as XML data structures.XML data structures are well known in the art and generally comprisedata tree structures, wherein a sub-tree and/or single data value may betargeted for action. Various data modules may be implemented to act onspecific data values or fields of the data as it is routed through thesystem, e.g., through the content router 200. For example, theprocessing logic 250 may include one or more data modules operable aloneor in combination to modify certain content or metadata for specificcontent nodes or devices. An illustrative example includes a data moduleoperable to modify content/metadata for a PIM device or other devicehaving different or reduced capabilities relative to other content nodes(300-1, 300-2, etc.), such as a user account. One or more datamodulation components may be used by the content router 200 to adapt androute content to various content nodes having disparate capabilities.

The data modulation component may include one or more data modules, eachhaving a path and target within the XML-tree structure of the payload(i.e., including content and/or metadata). Multiple data modules may becombined to carry out various actions on one or more segments of thepayload as they are routed to different content nodes. For example, acontact entry may include an address including separate data values forstreet address, city, and country. A first module may be operable toremove or delete the country information from the contact entry and asecond module may be operable to modify the street address to a maximumof 20 characters. The modulation may be performed to “fit” the contentand metadata to a particular content node, e.g., a mobile device or thelike. Thus, a data change (e.g., a command) sent from content router 200to a content node (e.g., a device) is modified by the processing logic250 to fit the receiving content node; as such, the data is manipulatedas needed for the particular content node or device. Further, in oneexample, data sent from the device to the server fulfilspayload-requirements because the data is redistributed to other contentnodes/devices (i.e., the content entry is returned to its originalstate) by the content router as described herein. Accordingly, data maybe modified when sending or receiving data from content nodes/deviceswithout losing any portion of the payload content.

As described herein for this example, the payload data (e.g., segments401, 402, 403) is structured and represented in an XML-schema (which isgenerally an XML-tree data structure). Before and after manipulating theXML-tree structure, the payload is represented based on the same payloadschema. Each node (tag/attribute) in the XML-tree structure is handledby an instruction (referred to as a “NodeInstruction”). Further, aninstruction for a node may delegate handling of child nodes to childinstructions. Additionally, in one example, NodeInstructions process thepayload as an XML-tree structure using JAVA®-classes, where eachNodeInstruction is represented by one instance of a JAVA®-class.

The data modulation logic targets the tailoring of content (removingportions of the content) not only in the payload to be sent to thedevice, but also in a shadow-payload, which is stored with the server,e.g., the repository 600 of content router 200. This Shadow-payload,together with the incoming payload, may be used to join and restore thepayload before any further content router processing is applied. Theshadow-payload itself is organized in the same node-structure as theoriginal payload to ensure that each NodeInstruction gets/puts theinformation needed. In one example, to meet the different needs ofNodeInstructions that may be implemented, the shadow-payload isorganized into two XML-trees-one to store/read device-side-informationand one to store/read content router-side-information duringtailoring/joining processes.

Accordingly, various modules operable to perform various tasks may beset-up as a set of tools usable to perform various data modulations ascontent and changes to content are routed through the content router. Inone example, a content router (such as content router 200) may includevarious default data modules for the handling of payloads, where newdata modules or modifications to existing data modules may be generatedas new content nodes are added or removed from the system. The exemplaryframework for adding modules in an XML schema, for example, isparticularly flexible and adaptable to various content nodes/devicesthat might be associated with the content router and community ofconnected content nodes. Additionally, data modulation within an XMLschema may quickly adapt to new content nodes and content requirements.

NodeInstructions generally include SingleNodeInstructions andMultiNodeInstructions. SingleNodeInstructions handle a single node ofthe XML-tree structure and its value only, whereas MultiNodeInstructionshandle a subset of a node's child nodes as a unit.SingleNodeInstructions may be implemented in a variety of differentimplementations to modulate node values. MultiNodeInstructions may begenerally divided into 3 subtypes: i) GenericMultiNodeInstruction, whichis the root instruction and allows generically adopting specializedinstructions for each child node, ii) UniformMultiNodeInstruction, whichhandles unique named child nodes, and iii) MultiNodeInstruction, whichhandles two or more targeted child nodes with specialized processes.

In one example, the data modulation starts with aGenericMultiNodeInstruction. Various examples ofGenericMultiNodeInstructions are illustrated in FIG. 17A. Further,examples of SingleNodeInstructions, which may be used for manipulatingvalues of a single node without sub nodes, are shown in FIG. 17B.Further, UniformMultiNodeInstructions, which may be used formanipulating a single node (without value) containing many uniform(named) child nodes, are illustrated in FIG. 17C.

Various aspects of exemplary Data Modulation structures (continuing withthe example of the XML schema) are illustrated generally in FIGS. 18A-E.In particular, an exemplary Root tag is illustrated in FIG. 18A;exemplary list nodes to be handled by specialized instructions isillustrated in FIG. 18B; and an exemplary handling of a single node bycutting the string is illustrated in FIG. 18C. Further, an exemplaryhandling of a multi node with m:n mapping is illustrated in FIG. 18D;and an exemplary handling of a multi node with 1:1 identification isillustrated in FIG. 18E. Those of skill in the art will recognize thatthese examples are illustrative only and that various other examples arepossible, whether within an XML schema or otherwise.

According to another example, the content router includes a datamodulation component operable to divide or split (and therefore referredto as a “splitter” component) certain content in a bidirectional manner.The splitter component may be part of or a feature of the datamodulation features described and include logic operable to carry outthe functions described herein. Further, the logic operable to carry outthe splitter component functions may be stored in the store and forwardlogic 210 and processing logic 250 of content router 200 (see, e.g.,FIG. 5).

Typically, when routing changes to content (e.g., add/update ofcontacts, events, etc.) from and to weaker content nodes (i.e., havingreduced or fewer capabilities for handling data), some content nodes maynot be capable of or desirable for handling the content change itself,but can handle “n” separate data changes (generally of a more simplenature) derived from the original single data change. For example, arecurrence rule in an events application stored as a single record on afirst content node may be “split” into “n” number of single events on asecond content node; a contact entry having multiple phone numbers on afirst content node may be split into “n” number of contacts with onephone number each on a second content node; and the like. As will bedescribed, the splitter component manages data changes from and toweaker devices without a loss of information by processing a single datachange as multiple data changes according to content node capabilities.

In one example, the splitter component splits or divides a change to adata record to a relatively weak content node (e.g., a remote device),referred to as the “Splitting” direction. In particular, the splittercomponent determines the content node capabilities or preferences andsplits, if necessary, one data change (from a content node via thecontent router) to “n” data changes to effectuate the data change. Anillustrative example includes a change to a recurring event, such as thetime of a weekly meeting. Some content nodes may be able to store theevent as a single record with a recurring attribute. Some content nodes,however, may not have the capability for recurring events and must storeindividual records for each event. Thus, a change to the recurring eventat a first content node is split or divided into two or more datachanges to effect the change to multiple event entries with the lesscapable, weaker content node.

For example, a recurrence event may be stored on a first content node,such as a PIM application server, as: Title Meeting with Sue Time 10-11am Start Date Friday 10 Jun. 2005 Recurrence Type Monthly End DateSaturday, 31 Dec. 2005

The recurrence event may be stored (and routed) on a second contentnode, which may be a less capable, weaker device, as two or more singleevent entries, the first entry as follows: Title Meeting with Sue Date10 Sep. 2005 Time 10-11 am

Additionally, the second entry may be stored with the content node asfollows: Title Meeting with Sue Date 10 Oct. 2005 Time 10-11 am

The single events in the device match those in the PIM applicationbackend because the Title and Time are the same and they match therecurrence details specified in the PIM application program (i.e., theyoccur on the 10^(th) of each month). A change to the recurrence event onthe first content node or a change to the single event entries on thesecond content node may be routed by the content router to change thecorresponding entries and preserve the recurrence aspect of the events.In particular, the single event entries and recurrence event entry maybe split or merged depending on the direction and content capabilities,thereby improving the ability to synchronize all connected content nodesin the community despite disparate capabilities of the various contentnodes.

Another illustrative example includes a contact having multiple phonenumbers. For example, “Joe Smith” may include three phone numbersassociated therewith. A particular content node or device may be capableof storing only one phone number per contact. Accordingly, the splittercomponent may operate to divide the contact entry of “Joe Smith” intotwo or more separate data entries for storage with the device, in thisexample, into three entries for “Joe Smith” having one phone number foreach.

The splitter component is also operable to perform “Integration” of therecord in a direction from the device to the server or other contentnodes, referred to as the “Integration” direction. In particular, anincoming device data change related to a former data change will resultin a corresponding (server) data change. For example: a phone number maybe reintegrated into a full content entry; move of a single eventresults in reintegrated into full recurrence as an exceptional event;and the like.

During initial import of data from a content node, such as a device,data is aggregated to a lesser count of data with the server. In oneexample, “n” data records are aggregated to one data record whenpossible. The content router further stores (e.g., in repository 600 orother memory associated therewith) this information from “Aggregation”processes for subsequent “Splitting” and “Integration” processes.

According to a third method, shown generally with reference to FIGS. 8Aand 8B, segments are not saved to a repository. The store and forwardlogic 210 may accommodate a limited capability content node by strippingor modifying an incompatible or undesired segment from the commandpayload. However, with this method, a copy of the stripped or modifiedsegment is not preserved in a repository. If those segments are neededlater, the store and forward logic 210 may request and receive thesegment from the source of the original incoming command.

FIG. 8A illustrates a process of stripping a segment of an exemplaryemail according to embodiments of the present invention. An incomingemail 900 arrives at a first content node 300-1 from the Internet overan SMTP connection. The email 900 includes a payload 901, which containsan incoming email header and body 401 containing information such asdate and time and to, from and reply email addresses as well as the textentered by the sender. The payload 901 also includes an image fileattachment 402, such as a JPEG file, and a presentation file attachment403 such as a PowerPoint presentation. An application running on thecontent node 300-1 may convert the attachments 402 and 403 to links 402Aand 403A, which allow a capable content node to access the attachmentsthrough the hyperlinks to the attachments. The content node 300-1 maythen create one or more messages 910, according to an email protocolsuch as IMAP, forming a payload 911 including the incoming email headerand body 401, the link to the image file 402A, and the link to thepresentation file attachment 403A. The content node 300-1 sends themessages 910 to protocol interface logic 260 within the content router200.

The protocol interface logic 260 converts the one or more messages 910into a command 420 containing a payload 421 including the incoming emailheader and body 401, the link to the image file 402A, and the link tothe presentation file attachment 403A extracted from payload 911. Theprotocol interface logic 260 allows for content nodes that use differentprotocols to function with the content router 200. The store and forwardlogic 210 receives the incoming command 420 from the protocol interfacelogic 260 and prepares an outgoing command 430 for content node 300-2.In this example, the content node 300-2 is unable to a processpresentation file attachment 403 or its link 402A. For this content node300-2, the store and forward logic 210 is configured to strip off anylinks to a presentation file attachment 403A. The store and forwardlogic 210 prepares the outgoing command 430 including a payload 431containing the incoming email header and body 401 and the link to theimage file 402A, but not the link to the presentation file attachment403A. In this case, the store and forward logic 210 does not preserve acopy of the link 403A in a repository 600 for later use.

After the content router 200 has forwarded a stripped email to contentnode 300-2, a user at content node 300-2 may forward the email to anexternal Internet address. When protocol interface logic 260 receivesthe forwarded email, it may determine that the email is missing one ormore segments contained in the original email. The protocol interfacelogic 260 may request the missing segments from an inbox at content node300-1 containing the complete email. After receiving the originalsegments, the protocol interface logic 260 may restore the segments tothe forwarded email. Next, the protocol interface logic 260 may use anemail server associated with inbox at content node 300-1 to forward theemail to the external Internet address.

FIG. 8B illustrates a process of restoring a stripped segment to anemail if a user later forwards the email according to embodiments of thepresent invention. A user may forward an email previously received atcontent node 300-2. For example, the content node 300-2 sends a command440 containing a payload 441 including a newly created outgoing emailheader and body 401B, the original incoming email header and body 401,and the link to the image file 402A. This incoming command 440 includesneither the presentation file attachment 403 nor its link 403A. Inresponse to receiving the incoming command 440, the store and forwardlogic 210 generates an outgoing command 450 including a payload 451containing the segments from payload 441.

The protocol interface logic 260 receives command 450 and detects thatit is a forwarded email. The protocol interface logic 260 may attempt torestore the stripped segments by requesting the unabridged email fromthe first content node 300-1. Alternatively, the protocol interfacelogic 260 may request just the stripped segments 402 and 403. Inresponse, the first content node 300-1 sends the protocol interfacelogic 260 the stripped segments, for example, in one or more IMAPmessages 960, forming a payload 961 that includes the image fileattachment 402 and the presentation file attachment 403.

The protocol interface logic 260 prepares an email containing a payload971 including the outgoing email header and body 401 B, the incomingemail header and body 401, the original image file attachment 402, andthe original presentation file attachment 403. The protocol interfacelogic 260 may forward the email to an email server 300-1A associatedwith content node 300-1, for example, in an SMTP message 970 includingpayload 971.

The email server 300-1A responds to the SMTP message 970 with anoutgoing email 980 to the external Internet address. The outgoing email980 contains each of restored segments of the incoming email that werepreviously stripped off or modified by the protocol interface logic 260.The outgoing email 980 also contains the outgoing email header and body401B created at content node 300-2. As a result, the outgoing email mayappear that it was forwarded from an email containing the originalattachments 402 and 403 even though the content node 300-2 from wherethe user forwarded the email had limited capabilities and receivedneither attachment.

A repository 600 may also be used for keeping an inventory ofinformation routed among connected content nodes. Alternatively, theinventory may be kept in separate memory. The inventory may includecharacteristics of content and/or characteristics of metadata of one ormore content types routed to and from the content router. The inventorymay be used for summarizing characteristics of routed content residingon one or more of the connected content nodes 300. The inventory may beused to preview an item count. For example, if one or more routingparameters are changed for a particular content node 300, the contentrouter 200 may estimate or determine the number of additional items of aparticular content type would need to be fetched from one or more othercontent nodes 300 to place the particular content node 300 in line withthe updated routing parameters. The characteristics may be used tocompute a summary number of a content type residing on a content nodefalling within a condition based on the characteristics in theinventory. The entries in the inventory may be counted to summarize anumber of a particular content type reside on a content node. In someembodiments, the inventory may be used during conflict checking toidentify duplicate commands.

For an email content type, the content router may collect information inan inventory from each email message routed through the content router200 and residing on a content node. For example, for each command to adda new email message, the content router 200 may save characteristics ofthe email such as the existence of the email and a date the email wasreceived by the content node. The entries in the inventory may becounted to summarize a number of email messages residing on a contentnode. The date of each email may be used to summarize a number of emailmessages residing on a content node falling within a specified daterange based on a date characteristic in the inventory for a plurality ofemail messages routed through the content router, If a user wishes tosee a number of email messages that a content node would contain if theuser changed a routing parameter, such as the number of days an emailshould reside on a content node, the content router 200 may compute thenumber of emails in an inventory that fall within a particular daterange.

The inventory may also be used by a scheduler on the content router 200to remove email messages from a content node 300 previously routedthrough the content router 200 to the content node 300. A scheduler onthe content router 200 may periodically compare dates in the inventoryof email messages previously routed through the content router 200. Forexample, the schedule may compare these dates to a routing parameterindicating a number of days a user as elected to maintain routed emailson the content node. The routing parameter may be to keep emails fromthe last three days on a user device, such as a mobile phone. New emailmessages may be forwarded to the user device as they arrive to thecontent router 200 and an inventory kept of each new email. As emailsare deleted by actions of a user at one or more content nodes, thecontent nodes sends email deletion commands to the content router andthe inventory may be updated accordingly. The scheduler may periodically(e.g., nightly) compare the dates of emails in the inventory to therouting parameter indicating that emails should only be kept on the userdevice for the certain number of days. If the inventory indicates thatthe user device contains email older that the routing parameter permits,the scheduler on the content router may generate a command to deleteeach email on the user device that is older than allowed by the routingparameter. For example, the routing parameter may indicate keeping a twoday history of emails on the user device. Each night the scheduler maystore a command to delete emails from the user device that are olderthan two days. Additionally, the inventory may be used to indicate to auser a number of emails that would need to be removed from or added to acontent node if a routing parameter where changed. For example, if arouting parameter for a content node currently indicated keeping twodays of emails were changed to keeping one day of email, the contentrouter 200 may determine from the inventory data associated with thecontent node that a particular number of email messages would need to bedeleted from the content node. Similarly, if the routing parameter werechanged from two days to three days for a particular content node 300,the content node 200 may determine, from inventory data related to theparticular content node 300 and to another related content node, thenumber of email messages that would need to be routed from the relatedcontent node to the particular content node.

Similarly, the inventory may be used by the content router to limit anumber of one or more content types on a content node. The contentrouter may send delete commands corresponding to each add command of acontent type wherein the content node already holds a predeterminednumber of content of a type. Alternatively, a scheduler may be used toperiodically determine if a content node has a number of content itemsin excess of predetermined threshold number for each content type. Thepredetermined threshold number may be configured by the user oralternatively may be a default value for the content node type. Forexample, if a content node, such as a mobile phone, may have 500 or moreemail messages. A content node, such has a user account may have alarger predetermined threshold number, such has 5000. For each new emailmessage added to the content node, the content router may send acorresponding delete command to remove the oldest email message from thecontent node. Alternatively, a scheduler may periodically determine if acontent node has more that a predetermined number of items of aparticular content type and then send one or more delete commands toremove outdated content. For example, a predetermined number may be 500,which may indicate that a particular user device may have up to 500emails. If the content router determines that the user device has morethan 500 emails, it may send a number of delete commands to remove emailmessages in excess of 500. In some embodiments, the content router sendsdelete commands to remove the oldest emails messages in excess of thepredetermined threshold number. When provisioning a content node, theinventory may be used to request the most recent 500 emails from othercontent nodes for forwarding to the provisioned content node. As newemails arrive, they may be added to the content node until apredetermined limit, such as 5000, is reached. Once the limit isreached, the content router may issue delete commands to remove theoldest email messages from the content node.

Similarly for events, the content node may have a predeterminedthreshold number for a maximum number of events on a content node. Foreach new event added to the content node, the content router may send adelete command to remove the oldest event if the predetermined thresholdnumber would otherwise be exceeded. Alternatively, the content routermay periodically review the inventory to determine a number ofevent-content types exist on a content node. It may then send one ormore delete commands to delete the oldest events from the content node.

Similarly for tasks, the content node may have a predetermined thresholdnumber for a maximum number of tasks on a content node. For each newtask added to the content node, the content router may send a deletecommand to remove the oldest task if the predetermined threshold numberwould otherwise be exceeded. Alternatively, the content router mayperiodically review the inventory to determine a number of task-contenttypes exist on a content node. The content router may then send one ormore delete commands to delete the oldest tasks from the content node.Alternatively, the content router may then send one or more deletecommands to delete completed tasks until the predetermined thresholdnumber is not exceeded.

Additionally, the content router 200 may calculate and save a checksumof the new email. The checksum may be used when determining if a commandto add a new email duplicates a command in the command memory or acommand previously passed through the content router.

FIGS. 9A to 9C show a structure of a store and forward logic 210 anddata path between processing logic 250 and content nodes 300-1 to 300-naccording to embodiments of the present invention.

FIG. 9A shows store and forward logic 210 having a command memory 220and processing logic 250. The processing logic 250 is coupled to aconnected data set configuration 500 and to the command memory 220. Thecommand memory 220 is also shown coupled to content nodes 300-1 to300-n. The command memory 220 may be configured to include both incomingmemory 230 and outgoing memory 240 for each content node 300. A contentnode 300 may push (put) one or more commands to the incoming memory 230.A content node 300 may also pull (get) one or more commands from theoutgoing memory 240.

Those skilled in the art will recognize that the incoming memory 230 andoutgoing memory may be formed using a database. For example, commandmemory 220 may be configured in a database containing commands. Eachcommand in the database may be associated with attributes. For example,an attribute associated with a command in the database may identify thecommand as an incoming command or an outgoing command for a particularcontent node 300.

FIG. 9B shows a structure of the command memory in the store and forwardlogic 210 for a single content node 300 according to embodiments of thepresent invention. The command memory 220 includes incoming memory 230and outgoing memory 240.

In some embodiments, the incoming memory 230 includes an incoming queue231 and a corresponding in-transit queue 232. The incoming queue 231holds incoming commands received by the store and forward logic 210 froma content node 300 but have not been responded to by the processinglogic 250. The corresponding incoming in-transit queue 232 holdsincoming commands that the processing logic 250 is in the process ofresponding to. Once an incoming command has been successfully respondedto by the processing logic 250, processing logic 250 may discard theincoming command from the in-transit queue 232. If the processing logic250 was unsuccessful at processing an incoming command, for example, ifa necessary resource is unavailable, the processing logic 250 may movethe incoming command from the in-transit queue 232 back to the incomingqueue 231.

In some embodiments, the outgoing memory 240 includes an outgoing queue241 and a corresponding in-transit queue 242. The outgoing queue 241holds outgoing commands generated by the processing logic 250 (inresponse to an incoming command) but the processing logic 250 has notinitiated sending of the outgoing command to the content node 300. Thecorresponding outgoing in-transit queue 242 holds outgoing commands thatthe processing logic 250 has initiated sending to the content node 300but a confirmation or assurance that the content node 300 has receivedthe outgoing command has not been received by the processing logic 250.

Those skilled in the art will again recognize that a database may usedto hold commands and that one or more attributes associated with eachcommand may indicate that the command is in the incoming queue 231, thecorresponding incoming in-transit queue 232, the outgoing queue 241, orthe corresponding outgoing in-transit queue 242.

FIG. 9C shows incoming memory 230-1 used for holding an incoming commandfrom a source content node 300-1 and outgoing memory 240-2 used forholding an outgoing command to a destination content node 300-2.

During a period when a source content node 300-1 is coupled to the storeand forward logic 210, the source content node 300-1 may send (put) acommand or set of commands to the content router 200. The processinglogic 250 may place the incoming command or set of commands the incomingqueue 231-1 associated with the source content node 300-1.

At some later point in time, the processing logic 250 may respond to anincoming command held in the incoming queue 231-1. As part of respondingto an incoming command in the incoming queue 231-1, the processing logic250 may move the incoming command from the incoming queue 231-1 to thein-transit queue 232-1 of the incoming memory 230-1. Additionally, theprocessing logic 250 may select a destination content node 300-2 forwhich it may generate an outgoing command. In general, the processinglogic 250 may select a set of destination content nodes to includemultiple destination content nodes, a single destination content node,or no destination content nodes. Next, the processing logic 250 mayplace the generated outgoing command in the outgoing queue 241-2 of adestination content node.

After the processing logic 250 has successfully prepared and written anoutgoing command to the outgoing queue 241-2, the processing logic 250may remove the incoming command from the in-transit queue 232-1 in theincoming memory 230-1. If the processing logic 250 is unsuccessful ateither preparing or writing the outgoing command, the processing logic250 may move the incoming command from the in-transit queue 232-1 backto the incoming queue 231-1. In this manner, an incoming command iseither successfully responded to or it is placed back into the incomingqueue 231-1 for a future attempt at processing the incoming command.

The processing logic 250 may send a notification to the content node300-2 to inform the content node 300 that an outgoing command is pendingin the outgoing queue 241-1. At some later point in time, thedestination content node 300-2 may request (pull) the outgoing commandfrom the outgoing queue 241-2. Alternatively, the content router 200 maypush the outgoing command to the destination content node 300-2. Afterthe process of sending the outgoing command to the destination contentnode 300-2 has been initiated but before the processing logic 250 hasdetermined that the outgoing command was successfully sent and/orreceived, the processing logic 250 may move the outgoing command fromthe outgoing queue 241-2 to the in-transit queue 242-2 associated withthe destination content node 300-2.

A success at sending and/or receiving may be internally determined bythe processing logic 250, determined by receipt of an instruction toremove the outgoing command, or determined by receipt of anacknowledgement (ACK) or an equivalent notification providing sufficientassurance that the outgoing command has been received by the destinationcontent node 300-2. Communicating an acknowledgement may be initiated bythe destination content node 300-2 or by an intermediary acting as aproxy for the destination content node 300-2 as described below withreference to FIGS. 15B, 15C, 16B and 16C.

If a negative acknowledgement (NACK) is received, an error is detected,a time-out has occurred, or the like, the outgoing command residing inthe in-transit queue 242-2 may be moved back to the outgoing queue241-2. As a result, if a failure is determined, for example a temporaryfailure, the processing logic 250 may have a future opportunity toresend the outgoing command from the outgoing queue 241-2 to thedestination content node 300-2. If the processing logic 250 determinesthat the failure is permanent, it may discard the command therebyavoiding a potential endless loop of transferring a command in and outof an in-transit queue 232, 242.

In this way, it is sufficiently confirmed that an outgoing command iseither received by the destination content node 300-2 or placed backinto the outgoing queue 241-2 for a future attempt at sending it to thedestination content node 300-2.

The act of moving commands between an incoming or outgoing queue 231,241 and a corresponding in-transit queue 232, 242 helps assure that acommand is only discarded after it has been properly responded to orsent. Additionally, the process of moving a command between the incomingor outgoing queue 231, 241 and the in-transit queue 232, 242 may occurwith an actual move of data from one allocated buffer to another.Alternatively, the process of moving between queues may occur virtuallyby changing a state of a flag or an attribute in a database.Additionally, each time a command enters either the incoming queue 231or the outgoing queue 241, for example from an in-transit queue 232 or242 after an error condition has occurred, the processing logic 250 mayperform a conflict check as described below.

In the examples described with respect to FIGS. 9A-9C, the incoming datachange commands might be stored in command memory 220 twice, e.g., inincoming memory 230-1 and outgoing memory 240-2. In particular, thecontent router 200 processes (for each targeted content node 200-2, 3, .. . ) data change commands from “incoming” command memory 230-1,depending on the content node putting the command, toward the “outgoing”command memory 240-2, depending on the content node getting the command.Thus, the data change command may be stored two times the number oftarget or connected content nodes. In other embodiments of contentrouter 200, as will be described with respect to FIGS. 9D-9F, the use ofcommand memory 220 for storing commands may be reduced.

One such embodiment of an exemplary content router 200 with reducedstorage is illustrated in FIG. 9D. In this example, incoming data changecommands are processed toward other connected content nodes, such ascontent node 300-2, without storing the incoming data change commands inincoming memory 230-1 of command memory 220 as described above withrespect to FIG. 9C. In particular, content node 300-1 forwards a datachange command to store and forward logic 210 of content router 200,where store and forward logic 210 attempts to immediately process androute the command to content node 300-2 (i.e., without first storing thecommand in incoming memory 230-1). For example, the change command isput from content node 300-1 directly to processing logic 250 of storeand forward logic 210, where processing logic 250 processes and routesthe command to the outgoing memory 240-2 (e.g., to outgoing queue 241-2and in-transit queue 242-2 as describe above). Thus, the incomingstorage (e.g., incoming memory 230-1; indicated in outline in FIG. 9D)may be eliminated, or at least its use limited, and only outgoingstorage (e.g., outgoing memory 240-2) used.

In one example, if processing logic 250 is unavailable or unsuccessfulin processing an incoming command from content node 300-1 (e.g., if aresource is unavailable or the like) incoming memory 230-1 may be usedto store the command as discussed with regard to FIG. 9C, for example.Thus, the example of FIG. 9D may be used alone or in combination withother methods/systems, such as that of FIG. 9C.

The exemplary content router 200 of FIG. 9D may reduce storagerequirements associated with the store and forward logic 210. Forexample, instead of command memory 220 storing commands twice for eachassociated content node (i.e., storage within incoming memory 230-1 andoutgoing memory 240-2; before and after processing by processing logic250), command memory 220 stores a single command for each associatedcontent node. For example, only the outgoing memory 240-2 is used foreach targeted content node. The reduction or elimination of incomingstorage to facilitate processing may reduce costs and increase the speedof content router 200 (as evident by the reduced processing and storagerequirements).

In another embodiment of content router 200, illustrated generally inFIG. 9E, the two storages (e.g., incoming storage 230-1 and outgoingstorage 240-2) are replaced by a single storage 222 for all contentnodes. In particular, incoming data change commands are processed byprocessing logic 250 in the context of the device “put”-requestimmediately to a central storage, or command memory 222 of contentrouter 200, where the command memory 222 is content node independent(e.g., command memory 222 is not adapted for or associated with aparticular content node). Outgoing data change commands are thenprocessed by processing logic 250 in the context of a contentnode/device “get”-request from the command memory 222 when routing tothe content nodes 300-2, 300-3, and 300-4.

In particular, when content node 300-1 puts data, it is pre-processed byprocessing logic 250 prior to storage in command memory 222. Forexample, various data modulation, splitter/aggregation processes, or thelike may be carried out on the data command prior to getting to commandmemory 222 such that a normalized data change command is held thereinand accessible by content router 200. In one example, the normalizedcommand stored with command memory 222 will represent the full scope ofthe change available from the first content node 300-1. As other contentnodes 300-2, 300-2, 300-4 are notified and “get” the data changecommand, or the data change command is otherwise routed thereto, datamodulation will occur (e.g., the data change command will be modulatedby processing logic 250 according to the particular content node as thedata change command flows to the particular content node).

Aspects of this example may reduce storage requirements of contentrouter 200 because the storage of data change commands may be reduced toa single entry accessible by all associated or connected content nodes(compare this single storage to previous examples that may store one ortwo commands per each connected or targeted content node). Additionally,the reduced storage may simplify the operation of store and forwardlogic 210 as shown in FIG. 9E relative to some other examples describedherein; however, it is noted that the content router will generally needto store additional information such as which content node has fetchedthe change command, etc. Once the data change command has been fetchedor received by each content node, the change command may be deleted fromcommand memory 222.

FIG. 9F illustrates another embodiment of an exemplary content router200, which may operate to push or directly write data change commands tocertain content nodes. As described in some of the examples above (e.g.,with respect to FIG. 9C), outgoing data change commands are stored in acommand memory 240-2. Content router 200 may notify the content nodes300-2, 300-3, and 300-4 of an available data change command, for whichthe respective content nodes may thereafter request the data changecommands from the content router 200. For highly capable content nodes,such as a user account associated with service provider backend (e.g., aYahoo!® User account and associated backend or the like), content router200 may not need to store these data change commands in command memory240-2; content router 200 may instead push or write the command directlythrough to the particular content node (sometimes referred to as“write-through”). Even highly available mobile user-devices may allow anexemplary content router system to write through directly (obviating theneed for storage of the outgoing commands in memory).

Thus, if content node 300-2 is available and capable when content router200 receives a data change command from content node 300-1, the datachange command may be processed by processing logic 250 and pushed tocontent node 300-2 (e.g., without using the outgoing command memory240-2 and waiting for content node 300-2 to request the command). Thus,these features of content router 200, as shown in FIG. 9F, maypotentially reduce the storage required or associated with contentrouter 200 relative to some of the examples described herein.

If a particular content node, e.g., content node 300-3, is not availableand/or capable to take the data change commands as described withrespect to content node 300-2, the data change commands for thatparticular content node may be stored in an outgoing memory 240-2(similar or identical to that described with reference to FIG. 9C, forexample) and a notification to content node 300-3 made. For example,content node 300-3 may be notified of the change command in outgoingmemory 240-2 via a technical SMS, or the like. Thereafter, content node300-3 may fetch the data change as previously described.

Additionally, in this example content router 200 may store states,filters, information about what content is on the various content nodes,the content node capabilities, and the like to assist in facilitatingthe direct write through or push to the content node(s). Suchinformation may be stored with or accessible by processing logic 250,connected data set configuration 500, and/or the like.

Those of ordinary skill in the art will further recognize that variousexamples of store and forward logic 210 as described with respect toFIGS. 9A-9E may be used alone or in combination with other methods andsystems (whether described herein or not). Additionally, variousexamples of store and forward logic 210 and its operation may be used asa primary process for routing data change commands with one or moreother examples serving as a secondary process for routing if the primaryprocess is unavailable (e.g., if a resource is unavailable, a contentnode is unavailable, or the like).

FIGS. 10A to 10D show a Put-Get-Ack procedure from points of view acontent node 300 and a content router 200 according to embodiments ofthe present invention. A goal of this procedure is to resolveconflicting commands within the incoming and outgoing queues 231, 241.By resolving conflicts within the incoming and outgoing queues 231, 241,content nodes 300 may be freed from the burden of resolving conflicts.

According to the PUT-GET-ACK procedure, a content node 300 first sends(PUTs) of all commands pending in the content node 300 to the contentrouter 200. The content router 200 resolves any conflict between anincoming command and a command already in either the incoming queue 231or outgoing queue 241. After the content node 300 has sent all commandsto the content router 200, the content node 300 receives (GETs) commandsfrom the outgoing queue 241. Finally, an acknowledgement (ACK) isreceived by the content router 200 assuring that the content node 300received the outgoing commands.

FIG. 10A shows a PUT-GET-ACK procedure between a content router 200 anda content node 300 from a point of view of the content node 300. At1100, a content node 300, such as a user device 310, waits until thereis a need or an ability to put a command to or get a command from thecontent router 200.

At 1101, a content node 300 receives a notification from the contentrouter 200 that a command is pending in the outgoing queue 241 and/orthe content node 300 determines that it has one or more commands to sendto the content router 200.

At 1102, the content node 300 first determines whether there are anycommands to send to the content router 200. By requiring that thecontent node 300 sends commands before receiving commands, resolution ofconflicts is handled in the content router 200 rather than by thecontent node 300.

At 1103, the content node 300 sends a request to PUT commands from thecontent node 300 to the content router 200. If the content node 300 hasone or more commands to put to the content router 200, it may send asequence of one or more individual requests each containing a payloadincluding a command. Alternatively, it may send a sequence of one ormore requests each containing a payload including batches of commands.

At 1104, the content node 300 receives an acknowledgement that thecommands were received by the content router 200. The content node 300then checks again at 1102 to determine whether there are any morecommands to put to the content router 200.

At 1105, if the content node 300 does not have any pending commands toput to the content router 200, the content node 300 next checks todetermine if there are any commands to get. In some embodiments, thecontent router 200 includes an indication in the acknowledgementreceived in 1104. The indication may inform the content node 300 that apending command is waiting in the outgoing queue 241. If no commandswere pushed to the content router 200, the content node 300 maydetermine that there may be one or more pending commands to get based onthe notification received earlier.

If there are commands to GET from the content router 200, at 1106, thecontent node 300 sends a request to the content router 200. At 1107, thecontent node 300 then receives a response having a payload containingthe one or more commands. At 1108, the content node 300 processes thecommands, which may include executing the commands or may simple savethe commands for future execution. At 1109, the content node 300 sendsto the content router 200 an acknowledgement (ACK) that the commandswere received and processed. At 1110, the content node 300 waits for aresponse that its acknowledgement (ACK) successfully was received by thecontent router 200.

Next, again at 1105, the content node 300 checks to see whether thereare any more commands to get. The content node 300 may determine whetherthe content router 200 has additional commands by examining the lastreceived response received at 1110. In some embodiments, a response maycontain an indication that one or more additional commands are pendingin the outgoing queue 241. In some embodiments, a response may containthe one or more additional commands that were pending in the outgoingqueue 241. In cases where the response contains an indication that oneor more additional commands are pending in the outgoing queue 241, thecontent node 300 continues by requesting and processing the commands at1106. In cases where the response contains the one or more additionalcommands, the content node 300 continues by processing the commands at1108.

FIG. 10B shows a PUT-GET-ACK procedure between a content router 200 anda content node 300 from the point of view of the content router 200receiving a new incoming command PUT to the content router 200 by thecontent node 300. At 1200, a content node 300 sends a new command to thecontent router 200, where the new command is destined for the incomingqueue 231.

At 1201, the processing logic 250 determines whether any conflict existsbetween the new command and any command existing in either the incomingqueue 231 or the outgoing queue 241.

At 1209, if a conflict exists between the new command and an existingcommand, the processing logic 250 resolves the conflict by determiningwhether to discard the new command, aggregate the new command with theexisting conflicting command, remove the existing conflicting commandfrom the queue 231 or 241, and/or move the new command to the incomingqueue 231. The process of detecting and resolving conflicts between anew command and an existing command is further described below withreference to FIG. 10D. At 1203, if no conflict is detected, theprocessing logic 250 moves the command to the incoming queue 231.

At a future time, the processing logic 250 begins processing commands inthe incoming queue 231 as shown at 1204. At 1205, once processing hasbeen initiated, the processing logic 250 may move the command from theincoming queue 231 to the in-transit queue 232. At 1206, the processinglogic 250 receives an acknowledgement that the command was processed,receives a negative acknowledgement that the command was not processed,or determines that due to a failure, such as a timeout, the command mustbe processed again.

At 1207, the processing logic 250 receives an acknowledgement.Therefore, the processing logic 250 removes and discards the commandfrom the in-transit queue 232. Alternatively at 1208, if a timelyacknowledgement is not received, the processing logic 250 prepares tomove the command from the in-transit queue 232 back to the incomingqueue 231 for reprocessing at 1204. At this point, the command to bemoved may be treated as a new command. At 1201A, the processing logic250 performs a conflict check between the command to be moved andcommands in the incoming and outgoing queues 231, 241 for the contentnode 300. The process then continues as described above with referenceto 1202.

FIG. 10C shows a PUT-GET-ACK procedure between a content router 200 anda content node 300 from the point of view of the content router 200generating a new outgoing command for a content node 300 to GET from thecontent router 200. At 1210, the content router 200 may generate a newoutgoing command in response to an incoming command from a differentconnected content node associated with the same user.

At 1211, the processing logic 250 determines whether any conflict existsbetween the new command and any command existing in either the incomingqueue 231 or the outgoing queue 241. At 1219, if a conflict existsbetween the new command and an existing command, the processing logic250 resolves the conflict by determining whether to discard the newcommand, aggregate the new command with the existing conflictingcommand, remove the existing conflicting command from the queue 231 or241, and/or move the new command to the outgoing queue 241. At 1213, ifno conflict is detected, the processing logic 250 moves command to theoutgoing queue 241. At 1214, the processing logic 250 may send anotification to the content node 300 to indicate that a new command iswaiting in the outgoing queue 241.

At a future time, the processing logic 250 begins processing thecommands in the outgoing queue 241. At 1215 once processing has beeninitiated, the processing logic 250 send a command from the outgoingqueue 241 to the content node 300. The processing logic 250 may alsomove the command from the outgoing queue 241 to the in-transit queue242. At 1216, the processing logic 250 waits for an acknowledgement fromthe content node 300 indicating that the command was processed by thecontent node 300. A failure may occur if the processing logic 250receives a negative acknowledgement that the command was not processedor determines that due to a failure, such as a timeout, the command mustbe processes again.

At 1217, the processing logic 250 receives an acknowledgement.Therefore, the processing logic 250 removes and discards the commandfrom the in-transit queue 242. Alternatively at 1218, if a timelyacknowledgement is not received, the processing logic 250 prepares tomove the command from the in-transit queue 242 back to the outgoingqueue 241 for reprocessing. At this point, the command to be moved maybe treated as a new command. At 1211 A, the processing logic 250performs a conflict check between the command to be moved and commandsin the incoming and outgoing queues 231, 241 for the content node 300.The process then continues as described above with reference to 1212.

FIG. 10D shows a structure for detecting conflicts between a new command400 and existing commands 401-407 in the incoming queue 231 and theoutgoing queue 241. A new command 400 may be received from a contentnode 300 or generated by the processing logic 250. New commands 400 froma content node 300 are destined for the incoming queue 231. New commands400 generated by the processing logic 250 are destined for the outgoingqueue 241. Before a new command 400 is saved in either the incomingqueue 231 or the outgoing queue 241, the processing logic 250 determineswhether a conflict exists.

To determine whether a conflict exists, the processing logic 250compares the new command 400 to existing commands 401-407 in theincoming queue 231 and/or the outgoing queue 241. If the new command 400and an existing queued command contain related content or metadata, theprocessing logic 250 may determine that a conflict must be resolvedbetween the new command 400 and this existing command.

To resolve a detected conflict, the processing logic 250 may determineif one command supersedes the other. In the case where the existingcommand supersedes the new command, the processing logic 250 may discardthe new command 400. In the case where the new command supersedes theexisting command, the processing logic 250 may either replace theexisting command with the new command 400 in the appropriate queue 231or 241, or it may remove the existing command from the queue 231 or 241and add the new command 400 as a new entry at a different location inthe appropriate queue 231 or 241.

Alternatively, the processing logic 250 may determine that the newcommand 400 and the command conflicting with the new command 400 shouldbe aggregated into a single command. In the case where commands areaggregated, the processing logic 250 may either replace the existingcommand with an aggregated command, or it may remove the existingcommand from the queue 231 or 241 and add the aggregated command as anew entry in the appropriate queue 231 or 241.

FIG. 11 illustrates a representation of a structure of a connected dataset configuration 800 according to embodiments of the present invention.A connected data set configuration database 800 includes a hierarchalconfiguration, e.g., 510 to 570, for each user connected to the contentrouter 200. A first user defines a connected data set configuration 510using a configuration and maintenance tool. The configuration andmaintenance tool may be, for example, a web based graphical userinterface (GUI) having access to the database 800 via SQL databasecalls.

Each user configuration 510 to 570 may include a configuration for userdevices 511 and for user accounts 516. Each configuration for userdevices 511 includes a set of configurations for each user device 512,513. Each configuration for user accounts 516 includes a set ofconfigurations for each user account 517, 518. Each user device andaccount configuration 512, 513, 517 and 518 includes a set ofconfigurations for each configured content type.

Those skilled in the art will recognize that the connected data setconfiguration database 800 may be structured using one of severalpossible hierarchal structures. For example, user devices configuration511 and user accounts configuration 516 may be combined into a singlestructure. The hierarchal structure between user devices or useraccounts and content type may be reversed such that a content typeconfiguration contains a configuration for multiple user devices and/oruser accounts, rather than having a user device or user accountconfiguration containing a configuration for multiple content type.

As shown, a user device configuration 513 contains a configuration foreach content type processed by the user device. For example, if userdevice B is capable of processing contacts, events, to do items (tasks),emails and library items, the user device B configuration 513 maycontain respective configurations 513-1, 513-2, 513-3, 513-4 and 513-5.A database ID may be allocated for each content type of a user'sconnected content nodes. Therefore, a database ID may have a one-to-onerelationship to a particular content type on a particular connectedcontent node for a particular user. This database ID may be used by acontent node when it communicates with the content router 200. Forexample, each command that is generated by a content node may include aspecific database ID to identify the user, the content node and thecontent type as described below with reference to FIG. 13.

When a new content node (e.g., a user account or device) enters theconnected community of content nodes, it is generally desirable to avoida situation where content or metadata (e.g. contacts, events, etc.)associated with the new content node is duplicated with that alreadyavailable in the connected community. Such a scenario may result in, forexample, if two identical or nearly identical content entries exist onone or more of the content nodes. Accordingly, the content router mayinclude logic operable to detect and handle duplicate content entries,in particular, when a content node is added to the community.

In one example, data consolidation logic is included with the store andforward logic 210 (e.g., with the processing logic) of the contentrouter 200 (see, e.g., FIG. 5). The data consolidation logic is operableto generate and maintain (e.g., store) a hash-value of at least aportion of the routed payload (including the content and/or metadata).In one example, the hash-value is created from at least one“significant” property of each payload, which is generally less than theentire content of the payload. The significant property may include aspecific data field depending on the content type, e.g., the first andlast name of a contact entry, a phone number for a contact, the subjectfield for an event entry, or the like.

The hash-value may be used to detect possible duplicates whenever newdata enters the community and query only these possible duplicate datacandidates for inspection. Further, by being based on a portion of thepayload (e.g., based on a significant property), non-exact matches maybe examined for possible duplicate entries. Such features may avoid thetime and cost of having to query all available data whenever new dataenters the community and reduce the potential for duplicates becausehash values may be relatively quickly compared with a list ofhash-values of known content.

In particular, a list of hash-values may be created and stored (e.g., inrepository 600 of content router 200 shown in FIG. 5) for all contententries associated with the community of connected nodes. As new dataenters the community via one or more content nodes 300-1, 300-2, 300-3,etc., a hash-value may be determined for each data entry or payload by asimilar process as for the original data. By comparing hash-values oftwo content entries, potential duplicates may be identified relativelyquickly compared with comparing the full data entries of old and newdata. When a potential duplicate is identified based on the generatedhash-values, various rules may be implemented to determine if thepotential duplicates are in fact duplicates and should therefore bestored separately, merged, ignored, or the like. Various rules todetermine actual duplicates may be used, and may depend, e.g., on thecontent type. In one example, a rule may be operable to determine anactual or potential duplicate if two content entries or records are anexact match, i.e., all data in all fields are exactly the same betweentwo content entries or records. For example, two contact entries mayboth consist of an identical name and phone number.

In other examples, various exceptions or modifications to an exact matchrule are possible and contemplated. For example, a first content nodemay include a contact entry with a first number of data fields, n. A newcontent entry may include a second number of data fields, n-1. Thehash-values may indicate potential duplicates based on similarsignificant properties (such as a name or phone number in a contententry). The content entries will not have an exact match, however,because the first content entry has additional, unmatched fields. Thesystem may nevertheless identify these as the same record and not createa duplicate entry for the new entry if, for example, all common datafields match. Additionally, the record which has the largest payload ornumber of segments/data fields may be used as a base record, whereby theother records are merged into the base record as appropriate. Additionalrules may be defined and used to equate data fields of different devicesand systems that do not include exact matches etc. For example, a firstcontact entry listing “John Smith” and a phone number, and secondcontact entry including “John Smith” and an email, are not exactmatches, but may be merged into a single record including “John Smith”and both the email and phone number data. The merged record will bedistributed to all content nodes (with some modifications or filteringpossible based on content node capabilities/preference/etc.).

For example, a first content node may include an event entry with arecurrence rule. A new event entry may include a single event occurringjust within that recurrence defined by the recurrence rule of the firstcontent entry. The hash-values may indicate potential duplicates basedon similar significant properties (such as the summary of a contententry). The content entries will not have an exact match, however,because the first content entry has additional recurring information andthe start date does not match. The system may nevertheless identifiesthese as the same record in one example and does not create a duplicateentry for the new entry if the single event occurs just within therecurrence defined by the recurrence rule of the first event.Additionally, the record which has the largest payload or number ofsegments/data fields may be used as a base record. The merged record, inthis case the recurring event, will be distributed to all content nodes(with some modifications or filtering possible based on content nodecapabilities/preference/etc.).

Accordingly, the hash-value provides a relatively fast and cheap processfor identifying potential duplicates (compared to storing or queryingthe actual content from varying content nodes). Additionally, variousrules may be defined and utilized to determine actual matches and thetreatment of those matches (e.g., to merge, discard, etc.).

With reference back to FIG. 13, a configuration 513-1 for contactcontent type of a particular content node (e.g., user device B 513) mayrequire a contact to include a phone number. For example, some mobilephones only allow a contact including a phone number. Alternately, auser may only want contacts with phone numbers on the user's device. Ifsuch a flag is set, all contacts without a phone number will not berouted to this content node. A flag may indicate that phone numbers mustbe digits only without other ASCII characters. In this case, arepository may be used as described below to hold an unfiltered versionof a ASCII filled phone number while the content router will prepare acontact include a digit-only phone number.

A configuration 513-2 for event content type of a particular contentnode may allow only events occurring within the next two weeks (or otherset future duration) to be routed to the content node. Therefore, if onecontent node sends a new event to the content router, the content routerwill determine if this event will occur within the predetermined futuretime. If the flag and duration indicate that the event falls outside theparameters, the content router will not route the event to this contentnode. Additionally, a content router may include an inventory asdescribed below that may be periodically reviewed to determine if anevent falls within the duration and may be retrieved from one contentnode and sent to this content node. Another flag may indicate that allattachments will be removed from an event before forwarding to thiscontent node. Another flag may indicate that all notes will be removedfrom an event before forwarding to this content node.

Similarly, a configuration 513-3 for to-do task content type of aparticular content node may allow only tasks due within the next twoweeks (or other set future duration) to be routed to the content node.

A configuration 513-4 for email is shown to include routing parametersused in routing rules and transformation parameters used intransformation rules. Routing rules may be used by the processing logic250 to select a set of destination content nodes. The set may be a nullset, whereby no content nodes are selected for receipt of an outgoingcommand. Alternatively, the set may indicate one or more destinationcontent nodes that may receive an outgoing command. Routing rulesinclude the capability of a content node to receive a particular contenttype, or an upper limit on a number of elements allowed on a contentnode. For example, a routing rule may be to bar any commands to a devicethat will increase the number of unread or read emails. A routingparameter may be a flag indication if the content node is or is notaccepting commands. For example, if the content node's email box isfull, the flag may be set to block sending of additional emails. Arouting parameter may indicate the maximum size of an acceptable input.For example, if a content node is a mobile phone with limited memory,the routing parameter may be used to block all email messages greaterthat a particular size (e.g., greater than 1 kilobyte). A routingparameter may indicate that the content router should block all commandsdestined to the content node if the connection speed is below apredetermined rate or if the connection type does not provide a hightransfer rate. For example, routing parameter may indicate that acontent node, such as a mobile phone, will not receive email messageswith attachments if the mobile phone is not connected with a wiredconnection.

For each selected destination content node, the processing logic 250 maygenerate an outgoing command. The processing logic 250 may usetransformation parameters when processing transformation rules.Transformation rules may be used to determine the contents of thegenerated outgoing command. For example, a transformation parameter maybe a maximum size value used to truncate commands to a maximum size(e.g., limiting the size to less than 1 kilobyte). A transformationparameter may be a flag used to determine whether a particular contenttype should be cut from the command. For example, a flag may be used toindicate that the content node only accepts attachments that are imagefiles. A transformation parameter may be a flag used to block allattachments. For example, a flag may be used to indicate that thecontent node does not accept attachments that are document files. Atransformation parameter may indicate that the content router shouldremove all attachments if the connection speed is below a predeterminedrate or if the connection type does not provide a high transfer rate.For example, transformation parameter may indicate that a content node,such as a mobile phone, accepts email messages with the attachments ifthe mobile phone is connected with a wired connection but indicates thatthe attachments may be stripped off if the mobile phone is connectedwith a wireless connection. A transformation parameter may be a flagused to block all attachments if the content node if approaching a fullstate. For example, a flag may be used to indicate that the content nodedoes not accept attachments when the content node is nearly full (e.g.,90% full). The content node may strip attachments from emails therebypreserving free memory on the content node.

A configuration 513-5 for library item content type of a particularcontent node may allow only images to be routed to the content node.Another flag may be used to filter audio files. Additionally, anotherflag may be used to filter movie files.

FIGS. 12A to 12E illustrate external and internal logic, which may beused to interface a content router 200 to user devices 310 and useraccounts 320 according to embodiments of the present invention. Acontent routing system may include the store and forward logic 210. Acontent routing system may also translation logic such as includeprotocol logic 260 and/or protocol interface logic. Additionally, acontent routing system may include a gateway such as a device gatewayand/or a server gateway. Alternatively, the gateway may be external tothe content routing system.

FIG. 12A illustrates a content router 200 coupled to an externalprotocol interface logic 260 and including a connected data setconfiguration 500 and store and forward logic 210 coupled to a commandinterface of protocol interface logic 260. The protocol interface logic260 may be used to couple the store and forward logic 210 with variouscontent nodes types such as user devices 310-1 to 310-3 and useraccounts 320-1 to 320-3 using interfaces having disparate protocols.

In the embodiment shown, the protocol interface logic 260 translatesbetween a protocol used by a content node 310, 320 and commands 400processed in the store and forward logic 210. Specifically, the protocolinterface logic 260 receives messages 910-1 to 910-3 and 920-1 to 920-3based on a specific content node protocol used to communicate with thecontent node 310-1 to 310-3 and user accounts 320-1 to 320-3. Theprotocol interface logic 260 converts these signals to commands 400 forthe store and forward logic 210. The protocol interface logic 260 alsoreceives commands 400 from the store and forward logic 210 and convertsthese commands back to messages 910-1 to 910-3 and 920-1 to 920-3tailored for the specific content node 310-1 to 310-3 and 320-1 to320-3.

As described above, a content router 200 couples to a command interfaceof the protocol interface logic 260. As described below, the contentrouter 200 couples to a message interface of protocol interface logic260.

FIG. 12B shows a content router 200 including store and forward logic210 and a protocol adapter 268 translating between messages 801 andcommands 400. The protocol interface logic 260 including a devicegateway 264 translating between messages 910 from a user device andmessages from the content router 200. The device gateway 264 couples thecontent router 200 with user devices utilizing various protocols. Thevarious user devices and protocols may include a mobile phone running aSyncML protocol or an SMS based protocol, a Java™ based client devicerunning a binary protocol, a home personal computer based client runningHTTP protocol, or the like.

The device gateway 264 performs a function of translating betweenvarious protocols used by the different user device types and a commonprotocol, such as a XML-RPC (extensible Markup Language-Remote ProcedureCalling) protocol, used by the content router 200. A common protocolallows for easier scalability when additional gateways also using thecommon protocol are coupled to the content router 200. Furthermore,using a common protocol decouples the function of device protocolconversion from the protocol adapter 268 as well as from the store andforward logic 210.

In addition to translating protocols, the device gateway 264 models aserver to support a client-server relationship from the point of view ofthe user device 310, which acts as a client. The device gateway 264 alsomodels a client to support a client-server relationship from the pointof view of the store and forward logic 210, which acts as a server.

In an alternative embodiment, the protocol adapter 268 is separate fromthe content router 200. The protocol adapter 268 may be part of theprotocol interface logic 260 or may be standalone.

Some user devices 310 may include a user interface application unawareof the content router 200. For these user devices 310, the user device310 may include a data routing driver knowledgeable of the contentrouter 200 and which interfaces with the user interface application. Thedata routing driver uses an available protocol to communicate with thecontent router 200 thereby coupling the user application with thecontent router 200. Commands received over the available protocol aretranslated into instructions for the user application. Additionally,changes made within the application are communicated as messages sentover the available protocol to the content router 200.

Some user devices 310 may include both a data routing driver and anapplication knowledgeable of the content router 200. Other user devices310, such as a SyncML-enabled mobile phone, may not need a data routingdriver knowledgeable of the content router 200 because of capabilitiesinherent in such devices. For example, a SyncML-enabled mobile phoneinherently includes over-the-air SyncML synchronization routinesinvokeable by the content router 200. Therefore, the content router 200may push changes to the SyncML-enabled mobile phone without requiringcontent router knowledgeable software on the user device 310.

FIG. 12C shows a content router 200 including store and forward logic210 and a protocol adapter 268 translating between messages 801 andcommands 400. The protocol interface logic 260 including a servergateway 266, which translates between messages 920 from a user accountand messages having a common protocol for use in the content router 200.The server gateway 266 couples the content router 200 with user accountsutilizing various protocols.

The server gateway 266 allows access to the content router 200 by useraccounts communicating according to various server protocols such asHTTP XML, J DAV, Web DAV Exchange, IMAP, POP3, or the like. The servermay include a PIM server, such as a Yahoo!® PIM server, a photo server,such as a Yahoo!® Photos server, an email server, such as a PacBellemail server, or the like. For example, a content node 320 may be auser's email account on an email server using an IMAP protocol tocommunicate to the content router 200.

Similar to the device gateway 264, the server gateway 266 models aclient to the store and forward logic 210. Unlike the device gateway264, which models an intermediary between a client and a server, theserver gateway 266 models an intermediary between two servers.Typically, two servers do not communicated in a client-serverrelationship. The server gateway 266, however, allows the account serverto communicate with the store and forward logic 210 server, both actingas servers in a client-server relationship. To facilitate thiscommunication, the server gateway 266 models a client to support aclient-server relationship from the point of view of the user account320 and models a client from the point of view of the store and forwardlogic 210.

As described above, the protocol interface logic 260 is positionedexternally from the content router 200. As described below, the contentroute 200 includes the protocol interface logic 260

FIG. 12D shows a content router 200 containing store and forward logic210, a protocol adapter 268, and protocol interface logic 260 includinga device gateway 264 and a server gateway 266. As described above, thedevice gateway 264 and a server gateway 266 translate between protocolsused by devices and servers and a common protocol, such as an XML-RPCprotocol. The protocol adapter 268 translates between the commonprotocol and commands 400 used to communicate with the store and forwardlogic 210. Commands 400 sent between the store and forward logic 210 andthe protocol adapter 268 may be in a request-response scheme such as ina Java™ platform including a Remote Method Invocation over InternetInter-ORB Protocol (RMI-IIOP) technology interface. A Java RMI platformallows an object running on a Java enabled content node to invokemethods on an object running in a Java based store and forward logic 210and vise versa. Furthermore, the content router 200 may configure thedevice gateway 264 and/or the server gateway 266 with one or more of therouting parameters and/or one or more of the transformation parameters,such that the gateway may perform routing and transformations oncommands of a content node.

The device gateway 264 is shown coupling the protocol adapter 268 to amobile phone 310-1 running a SyncML protocol 910-1 and a Java™ basedclient device 310-2 operating with a binary protocol 910-2. The servergateway 266 is shown coupling the protocol adapter 268 to a PIM server320-1, a photo server 320-2, and an email server 320-3 with protocols920-1, 920-2, and 920-3, respectively.

A common protocol, such as XML-RPC, allows applications running ondisparate operating systems and in different environments to make remoteprocedure calls using HTTP as a transport layer and XML as an encodingscheme. The XML-RPC protocol allows complex data structures to betransmitted from an application running on the device gateway 264, theserver gateway 266, an XML-RPC-enabled device, or an XML-RPC-enabledserver to the protocol adapter 268 and the store and forward logic 210.The protocol adapter 268 or the store and forward logic 210 may processthe received data structure and return a result to the application.

Content nodes having the capability to communicate using the commonprotocol may bypass the gateway and may communicate directly with theprotocol adapter 268. For example, a Symbian device or a WinCE, Win32 orhome personal computer (PC) 310-3 running a client application maycommunicate directly with the protocol adapter 268 and avoids the devicegateway 264 since the PC 310-3 already employs the common protocol.Additionally, a smart phone 310-4 may also communicate using the commonprotocol and avoid the device gateway 264. Similarly, user accounts mayuse the common protocol thereby bypassing the server gateway 266 tocommunicate with the protocol adapter 268. As shown, a Yahoo!® server320-4 uses the common protocol thereby avoiding the server gateway 266.In some embodiments, a content node communicates with commands 400directly (not shown), and thus may avoid using a protocol adapter 268.

By using a common protocol, the protocol adapter 268 may treat messages801 from device gateway 264, messages 803 from a server gateway 266,messages 810-3, 810-4 from user devices 310-3, 310-4 and messages 820-4from user accounts 320-4 similarly, thereby simplifying the design andimplementation of the protocol adapter 268. Therefore, incoming messagesin the common protocol are treated similarly regardless of input path tothe protocol adapter 268. As a result, the store and forward logic 210may treat commands from each content node similarly.

The content router 200 may also include a notification signal (dottedline) sent from the store and forward logic 210 to a device and/orserver gateway 264, 266 as shown in FIG. 12D. If an outgoing command iswaiting in the outgoing queue 241, the store and forward logic 210 mayperiodically send a notification signal (dotted lines) to theappropriate gateway 264, 266. A notification may be send from the storeand forward logic 210 to the gateway 264, 266 using telnet, HTTP, acustom API, or the like. The gateway 264, 266 then may initiate arequest for the outgoing command or commands 400 from the store andforward logic 210. The gateway 264, 266 may receive a response includingthe command from the outgoing queue 241.

In some embodiment, after a gateway 264, 266 receives a notificationsignal and fetches an outgoing command, the gateway prepares an outgoingnotification message containing the command. If the outgoing command isrelatively small in size, the gateway 264, 266 may include the commandwithin the notification.

According to some embodiments, the store and forward logic 210determines that a notification may be sent to a content node 300 toinform the content node 300 that the outgoing queue may contain anoutgoing command. The store and forward logic 210 generates anotification signal for a gateway 264, 266. The gateway 264, 266receives a notification signal from the store and forward logic 210. Thenotification signal may indicate availability of an outgoing command inthe outgoing queue 241 for a content node 300. In response to receivingthe notification signal, the gateway 264, 266 may request the outgoingcommand, for example, by a call to the protocol adapter 268. Theprotocol adapter 268 retrieves the command from the store and forwardlogic 210, which provides it to the gateway 264, 266. The gateway 264,266 receives the response containing the outgoing command. The gateway264, 266 prepares an outgoing notification containing the outgoingcommand. The gateway 264, 266 may encode the outgoing command into acompact binary sequence. The gateway 264, 266 then sends the outgoingnotification to the content node 300, which may be either a user device310 such as a mobile phone or a user account 320 such as an emailaccount. For example, a device gateway 264 may send the outgoingnotification to a mobile phone by way of an SMS gateway. The gateway264, 266 may send an acknowledge that the outgoing notification to thestore and forward logic 210 via the protocol adapter 268.

FIG. 12E shows a multi-server content routing system according toembodiments of the present invention. The content router 200 operates asa first server. The content router 200 includes store and forward logic210 and a protocol adapter 268, which may communicate internally via acommand based exchange, such as with RMI-IIOP, and externally via acommon protocol, such as XML-RPC. The content router 200 may alsoinclude a connected data set configuration 500 and/or a repository 600and/or a file relay server 700 either internally to or externally fromthe content router 200. Furthermore, the command memory 220, theconnected data set configuration 500, the repository 600, and the filerelay server 700 may each be formed in separate memory, combined in acommon memory, or formed in a combination of separate and combinedmemory. For example, the command memory 220, the connected data setconfiguration 500, the repository 600, and the file relay server 700 mayeach be formed in separate databases, such as separate relationaldatabases, or two or more may be combined a combined database.

The content routing system also includes servers to communicate tocontent nodes. A device gateway (server) 264 interfaces to user devices310 using device specific protocols 910. A server gateway (server) 266interfaces to user accounts 320 using server specific protocols 920.

Some embodiments of the present inventions include or are coupled to afile relay server 700. The file relay server 700 acts as a file relaymemory and may be coupled to one or more of the servers and/or contentrouter 200 (direct connection not shown in figure) and/or one or more ofthe content nodes.

The file relay server 700 facilitates transportation of commands havingseparable segments among a plurality of content nodes comprisingdetaching the segments prior to the commands being saved to a commandmemory of a store and forward logic. The file relay server 700 mayprovide an input for a content node 310, 320, a server 264, 266, or acontent router 200 (a protocol adapter 268 or a store and forward logic210) to store one or more files so that the files may be removed fromincoming commands before the incoming command is stored in the commandmemory 220 of the store and forward logic 210. By removing separablesegments, especially large files, the command memory is capable ofholding a larger number of commands and may be more agile in processingcommands. The file relay server 700 may also provide a mechanism forrouting file from and to a content node behind a firewall. Two contentnodes 300 separated by a firewall may not permission to access content,such as a file, and metadata from the other. However, if both contentnodes 300 are able to provide the content and/or metadata to the filerelay server 700 either directly or indirectly through a server 264,266, a content router 200, a protocol adapter 268, or a store andforward logic 210, the content nodes 300 may, in effect, exchange thecontent and/or metadata. Additionally, in some embodiments, a file isencrypted by the content node 310,320, a server 264, 266, a contentrouter 200, a protocol adapter 268, or a store and forward logic 210before it is saved to the file relay server 700. In some embodiments, asecurity mechanism is implemented so that a file provided by one contentnode are only available to other content nodes connected to the sameuser, for example, as configured in the connected data set configurationfor that users. A security mechanism may include authentication of eachrequest for a file from the file relay server 700, as well encryption ofthe received and delivered files.

The multi-server content routing system may use the file relay server700 to provide a path for a content node to receive an attachment when apeer-to-peer 450 connection, as shown in FIG. 5, is not desirable or notpossible. A peer-to-peer 450 connection may not be possible when one orboth of the content nodes are behind firewalls that block peer-to-peerconnections. Additionally, a peer-to-peer 450 connection may not bepossible when each content node is not simultaneously connected to thenetwork 10. The file relay server 700 may provide a temporary repositoryfor attachments or other segments of a command.

The file relay server 700 may off load processing form the store andforward logic 210. For example, a source content node, a device gatewayor a protocol adapter may cut a detachable segment from an incomingcommand or message, such as a large file from an email. A reference tothe stored segment on the file relay server 700 may be positioned inplace of the removed segment in the incoming command. The content router200 and connected content nodes 300 may process a reference to a fileresiding on the file relay server 700 in a similar manner as a referenceback to a file residing on the source content node 300. The resultingabridged incoming command may then be sent to the store and forwardlogic 210 and may be significantly smaller by the removal or replacementwith a reference of a large segment. At some subsequent time, anoutgoing command corresponding to the abridged incoming command may passout from the store and forward logic 210. The protocol adapter, devicegateway or a destination content node may detect the reference andreplace the reference with the segment retrieved from the file relayserver 700. In this way, the command memory 220 may be spared the taskof holding large files.

In a first scenario, a stand alone file relay server 700 is used. First,a new email including an attachment is received via the Internet by auser's corporate email account. The user account communicates a change,that is, the arrival of the new email to the content router 200. Thestore and forward logic 210 receives an incoming command containing theemail, however, the content node 300 replaced the attachment in theemail with a metadata link identifying the location of the attachment onthe corporate server. If the email account is behind a firewall, otherconnected content nodes may not be able to access a metadata link to theattachment. In this case, the store and forward logic 210 may forwardthe metadata link to the protocol interface logic 260 and may instructthe protocol interface logic 260 to fetch the attachment based on themetadata link. The protocol interface logic 260 directs the fetchedattachment to the file relay server 700. When generating outgoingcommands in response to the incoming command, the store and forwardlogic 210 replaces the metadata link identifying the corporate server asthe source of the attachment with a link locating the attachment on thefile relay server 700. A content node receiving the outgoing commandwill be referred to the file relay server 700 rather than to aninaccessible server.

In a second scenario, a public email server is used as the file relayserver 700. As was described above, a new email including an attachmentis received via the Internet by a user's corporate email account. Theuser account communicates the arrival of the new email to the store andforward logic 210 with a reference to the attachment rather than theattachment itself. The store and forward logic 210 instructs theprotocol interface logic 260 to fetch the attachment based on thereference. In this scenario, the protocol interface logic 260 directsthe attachment to a command destined for the public email server. Thestore and forward logic 210 then generates commands to each of the otherconnected content nodes with a metadata link directing a user to thepublic email server rather than the corporate email server. In this way,a content node may have access to an attachment that originated on anemail server inaccessible to the content node.

In another scenario, a first content node sends an incoming commandincluding an embedded attachment to the content router 200. The gateway264 or 266 removes the attachment from the command and saves theattachment to the file relay server 700. The gateway may remove allattachments or alternately particular attachment types. The gateway maybase the decision to remove one or more attachments base on one or moreconfiguration parameters, which may be specific to a content node, acontent node type and/or a user's connected data set configuration. Thegateway may replace the attachment with a reference, which may allow agateway or a content node itself to retrieve the attachment from thefile relay server 700. Alternatively, the protocol adapter 268 or thestore and forward logic 210 may swap the attachment and a reference inthe command and store to and/or retrieve the attachment from the filerelay server 700.

In some embodiments, the content node 310 or 320 interfaces with thefile relay server 700. For example, if a user account 320 receives anemail with an attached file from the Internet, it may forward the emailto the content router 200 as a command to add a new email containing afile. Alternatively, the user account 320 may detach then forward thefile to the file relay server 700. The content node 320 then generatesand sends a command with the email having the attachment replaced with areference to the file on the file relay server 700. When a destinationcontent node, for example, user device 310, receives an outgoing commandwith the reference, the content node 310 may automatically retrieve thefile from the file relay serer 700 and replace the reference with theretrieved file to restore the original email. Alternatively, the contentnode 310 may allow the user to manually fetch the file by following thereference to the file relay server 700.

In some embodiments, the gateways 264, 266 interfaces with the filerelay server 700. For example, if a gateway 264, 266 receives anincoming command from a source content node 310 or 320 to add a newemail containing an attached file, the gateway 264, 266 receiving theincoming command may forward the file to the file relay server 700 thensubstitute the file in the command with a reference to the file on thefile relay server 700. At some later point in time when an outgoingcommand that contains the reference is sent towards a destinationcontent node, the server 264, 266 receiving command from the contentrouter 200 may restore the email by replacing the reference with thefile extracted from the file relay server 700.

In some embodiments, the protocol adapter 268 interfaces (not shown)with the file relay server 700. For example, if the protocol adapter 268receives an incoming command from a source content node 310, 320 to adda new email containing a file, the protocol adapter 268 may forward thefile to the file relay server 700. The protocol adapter 268 thenreplaces the attached file with a reference to the file on the filerelay server 700. When a destination content node 310, 320 requests anoutgoing command that contains the reference, the protocol adapter 268may replace the reference with the file extracted from the file relayserver 700.

In some embodiments, the store and forward logic 210 interfaces (notshown) with the file relay server 700. For example, if the store andforward logic 210 receives an incoming command from a source contentnode 310, 320 to add a new email containing a file, the store andforward logic 210 may forward the file to the file relay server 700. Thestore and forward logic 210 then replaces the file in the command with areference to the file on the file relay server 700. When the store andforward logic 210 retrieves an outgoing command that contains thereference, it may replace the reference with the file extracted from thefile relay server 700.

FIGS. 13 and 14A to 14I show structures of various commands according toembodiments of the present invention.

FIG. 13 shows a command associated with a primary key and databaseidentifier according to embodiments of the present invention. The termcommand includes notifications and messages (which need not necessarilybe in a “command” format) of such changes that may be acted uponaccordingly by a receiver of the notifications and messages, such ascontent node. In some embodiments, a command includes a primary key thatis a monotonically increasing value assigned by the processing logic 250to each incoming command. The primary key is unique for all commandsassociated with a user. The primary key may also be unique for allcommands associated with all users. In some embodiments, a time stampmay be used as the primary key.

A command is also associated with a database identifier. The databaseidentifier may be used as an index or key into a database includingcommands from multiple users and multiple content nodes. The databaseidentifier may be a sequentially increasing number assigned by thedatabase for each content node and content type being added to thedatabase. Therefore, the database identifier may specifically identify,either indirectly or directly, a particular user, a particular contentnode or content node type, and a particular content type. A content nodeidentifier may include an identifier to a particular user device or useraccount. A content type may include an indication of one of a Contactitem, an Event item, a ToDo item, an Email item, or a Library item. TheLibrary item may be used to indicate one of ConnectedPhoto metadata,ConnectedDocuments metadata, or ConnectedMusic metadata.

A command may also be associated with a queue identifier indicatingwhether the command may be considered to reside in an incoming queue231, an incoming in-transit queue 232, an outgoing queue 241, or anoutgoing in-transit queue 242. The command may be stored as an entryinto a database, such as a SQL database, with associated attributesincluding the primary key, the database identifier and the queueidentifier.

A command may contain a command type and a payload. The payload mayinclude the content itself. Alternatively, the payload may includemetadata, or may include both the content and metadata. Metadataprovides information concerning the quality, condition, and othercharacteristics of the content. Metadata may include information such asa description of the content, an indication of a change to the content,and/or a reference or link to a source of the content.

The command type indicates an action taken or requested. In someembodiments, the command type indicates one of a list of actionsincluding: add, update, delete, get, get-results, query, query-result,query-end and clear. For incoming commands, the command type indicates achange that has occurred. For example, a command received with an addcommand type means that content was added to the content node. Foroutgoing commands, the command type indicates a change that the contentrouter is requesting to occur on a content node in order to keep thecontent node synchronized with a content node where a change was made.For example, an add command type means that the content specified in thepayload should be added to the content node.

A command having a command type of add indicates an action of adding acontent record to a content node. Payload for an add-command type mayinclude the content itself, metadata about the content and/or areference to the content.

A command having a command type of delete indicates an action ofdeleting a content record from a content node. Payload for adelete-command type may include metadata indicating which content and/ormetadata about the content to delete.

A command having a command type of get indicates a request for gettingthe contents of a record from a content node. Payload for a get-commandtype may include metadata indicating which content and/or metadata aboutthe content to get. A command having a command type of get-result is acommand sent in response to a get-command type. Payload for a get-resulttype may include the content itself, metadata about the content and/or areference to the content.

A command having a command type of query indicates a request for acategory of content from a content node. Payload for a query-commandtype indicates the category of content being requested. Thequery-command type may be used to request all content on a content node,or all content having particular characteristics. A command having acommand type of query-result indicates a response to a query-commandtype. Payload for a query-result-command type includes the requestedcontent or metadata about the content. The query-result-commands may besent by the content node 300 in multiple batches; therefore the contentrouter 200 may need to given an indication of when the query resultsflow has finished. The final response to a query-command type isindicated in a command having a command type of query-end. The Payloadfor a query-end-command type may be either the final content having theparticular characteristic or a null thereby indicated an empty setresponse. If no results are found, a query-command type results in aquery-end-command type indicating a null response. If a single result isfound, a query-command type results in a query-end-command typeindicating a matching response. If more than one result is found, aquery-command type results in one or more query-result-command typesfollowed by a query-end-command type containing the final match.

A command having a command type of clear instructs a content node toremove a category of content indicated by the payload. A command havinga command type of refresh instructs the content router 200 to recoverthe sending content node. Depending on the content node capabilities andthe user configuration in the connected data set configuration,recovering may be initiated by either sending the content node 300 aclear command to clear its content or a query command to import all itsdata. In either case, the content node 300 may receive a consolidatedcontent and metadata from one or more of the other content nodes, suchthat the content node 300 may be in-synch with connected content nodes.

The command also includes a data payload having a format dependent onthe command type and data type. The data payload may contain a changedrecord or may contain metadata such as a link or reference to thechanged record located at the data source or at a file relay server.

FIG. 14A shows a new email to be added to a content node. The datapayload includes an email ID used to uniquely identify an email, aheader, the first 2 kilobytes of the message and a link to the originalmessage. FIG. 14B shows a command to instruct content nodes that anemail has been read. FIG. 14C shows a command to delete a particularemail.

FIG. 14D shows a command to add a new audio file. FIG. 14E shows acommand to delete an audio file. FIG. 14F shows a command to add a newappointment. FIG. 14G shows a command to add a new contact where thecommand contains the record. FIG. 14H shows a command to update a newcontact where the command also contains the record. FIG. 14I shows acommand to add a photo image. The photo itself is not included in thecommand but a reference to the original photo image may be included.

FIGS. 15A to 15C illustrate sequence diagrams showing signaling betweena user device 310 and store and forward logic 210 according toembodiments of the present invention.

FIG. 15A shows a sequence when a user device 310 pushes one or morecommands to a content router 200. A user device 310, such as a mobile PCwith wireless capabilities, may undergo a series of changes to contentand metadata on the user device 310. An application running on the userdevice 310 may periodically prepare a payload indicating the changesmade during the period or may send commands when it regains wirelesscommunications. Using a protocol available to the user device 310, theapplication prepares a REQUEST message to put a payload containing alist of commands. For example, a user may have received a new SMSmessage AAA. Therefore, the application may generate a commandindicating that connected content nodes may add a new email AAA.Additionally, the user may have deleted an event BBB from a calendar andupdated a contact CCC with a work phone number. In some embodiments, abatch of commands is limited to include only commands operating on acommon command type. For example, a batch of commands may include onlycommands add, delete or modify email messages.

Those skilled in the art will recognize that a user device 310 may usevarious protocols to communication with the device gateway 264.Therefore, the REQUEST-RESPONSE protocol shown here is just onepossibility. According to embodiments of the invention, eachREQUEST-RESPONSE is an atomic pair of commands, where both commands mustoccur otherwise neither is considered successful. Unlike other protocolsrequiring multiple REQUEST-RESPONSE pairs, each REQUEST-RESPONSE pairaccording to the present invention may make progress in performing atask. For a wireless network, a long sequence of pairs of commands has agreater probability of incurring and interruption. Therefore, the singleREQUEST-RESPONSE atomic pair provides optimal reliability and throughput.

The user device 310 sends the REQUEST to put commands contained in itspayload to a device gateway 264, which models a server to the userdevice 310. In modeling a server, the device gateway 264 acts on andresponds to requests. The device gateway 264 translates from the deviceprotocol to the internally used protocol, and then sends to the protocoladapter 268 a REQUEST indicating a put of the commands indicated in thepayload. Alternatively, if the user device 310 was enabled tocommunicate using the internal protocol, the device gateway 264 may bebypassed.

The protocol adapter 268 converts the payload of the REQUEST to asequence of commands (e.g., add, delete and update) and sends (puts) thecommands to the store and forward logic 210 for the store and forwardlogic 210 to process. The store and forward logic 210 may assign amonotonically increasing primary key (e.g., 0010021, 0010022 and0010023) to each command for internal use. Furthermore for each command,the store and forward logic 210 may determine a database ID, which mayuniquely identify a user, a particular content node, and a content type.The store and forward logic 210 may also set the queue ID for eachcommand to indicate that the command is an incoming or outgoing commandthat is pending execution or pending acknowledgement of successfulexecution. The store and forward logic 210 may perform a conflict checkagainst each of the commands associated with the same database ID. If noconflicts are detected, the commands may be stored in the database withthe assigned attributes. If a conflict is detected, the store andforward logic 210 resolves the conflict by removing a command existingin the database, discarding the incoming conflicting command, and/oraggregating the incoming command and the existing command.

In response to successful processing and entry into the incoming queue,the store and forward logic 210 returns an indication of the success tothe protocol adapter 268. The protocol adapter 268 in turn responds tothe REQUEST from the device gateway 264 with a RESPONSE that indicatessuccessful forwarding of all of the commands received in the REQUEST.Likewise, the successful processing of the REQUEST from the user device310 is acknowledged with a RESPONSE indicating the success as shown. Auser device 310 receiving the RESPONSE indicating a success may discardthe payload of commands sent earlier. If the user device 310 fails toreceive this acknowledgement, it may resend the payload of commands in asubsequent REQUEST.

In accordance with embodiments of the present invention, a user device310 completes a transaction with the content router 200 with a singleREQUEST-RESPONSE exchange as shown. A single REQUEST-RESPONSE exchangereduces the change of an error interrupting a session as would occur ifa protocol required multiple REQUEST-RESPONSE exchanges to complete atransaction. Each request and response pair is designed to makeprogress, unlike multi-pair protocols. In a multi-pair protocol, if afailure occurs midstream all progress is lost and the entire sessionmust be restarted from the beginning. Therefore, in accordance withembodiments of the present invention, each successful singleREQUEST-RESPONSE exchange makes progress towards completing a task ofsynchronizing content nodes and any failure effects only the singleREQUEST-RESPONSE exchange.

FIG. 15B shows a sequence when a user device 310 requests (pulls)commands from a content router 200 after a notification is received.Once the store and forward logic 210 generates and stores a new outgoingcommand in the outgoing queue 24 1, the store and forward logic 210 maygenerate a notification signal to instruct the device gateway 264 tosend a notification to the user device 310. The notification may or maynot include an indication of content type. The device gateway 264 maycollect a series of notifications destined for a content node and mayperiodically send the collected notifications to the user device 310,for example, using an HTTP packet, if available, or an SMS message.Notifications may be sent with little delay if a user device 310 isconnected to the network 10 with a cost free channel or a channel ofnegligible cost, such as if it is docked to a wired internet connection.Notifications may be collected and send at frequent intervals if theuser device 310 is connected with an inexpensive channel, such as with aGPRS connection. Notifications may be collected and sent infrequently ifuser device 310 is connected with an expensive channel, such as a SMSconnection. In some embodiments, the content routing system keeps a flagupdated to indicate a current connection type, thereby providing avariable the content routing system may use when determining a frequencyof updating a content node.

After receiving the notification, the user device 310 may begin a singleREQUEST-RESPONSE session to get a content type of pending commands. Theuser device 310 sends the device gateway 264 a REQUEST to get contenttype of the pending commands. The device gateway 264 replies with aRESPONSE to the REQUEST including an indication of the content type ofthe pending command.

After receiving the content type, the user device 310 may begin a singleREQUEST-RESPONSE session to get a single command or batch of pendingcommands. The user device 310 sends the device gateway 264 a REQUEST toget pending commands. The device gateway 264 converts the REQUEST fromthe external protocol used by the user device 320 to a common internalprotocol. The device gateway 264 sends the REQUEST in the commonprotocol to the protocol adapter 268. The protocol adapter 268 convertsthe REQUEST to a call to get commands from the outgoing queue 241. Thestore and forward logic 210 returns a payload containing a batch ofcommands from the outgoing queue 241. Alternatively, the store andforward logic 210 may return a single command at a time, which theprotocol adapter 268 may combine to form a batch of commands. Theprotocol adapter 268 may associated an index to indicate the number ofcommands in the payload. The protocol adapter 268 replies to the REQUESTreceived from the device gateway 264 with a RESPONSE containing thepayload of commands to be executed by the user device 310.Alternatively, the protocol adapter 268 may reply with a single commandat a time in each response. The device gateway 264 forwards the RESPONSEas a RESPONSE to the REQUEST originally received from the user device310.

Some time after the initial REQUEST-RESPONSE exchange, the user device310 begins a second REQUEST-RESPONSE exchange to acknowledge successfulprocessing of the commands. The device gateway 264 forwards thisacknowledgement to the protocol adapter 268, which make a call to removecommands from the in-transit queue 242 in the store and forward logic210. The store and forward logic 210 returns a success. The protocoladapter 268 replies to the REQUEST with a RESPONSE acknowledging thesuccess. The device gateway 264 then replies to the REQUEST from theuser device 310 with a RESPONSE acknowledging the success.

FIG. 15C shows a sequence of events when a content router 200 pushes acommand within a notification to a user device 310. In some embodiments,the store and forward logic 210 includes a low priority and/orrelatively small payload within a notification. For example, the factthat an email has been read may be considered a low priority and smallbyte sized event. Such low priority events may be communicated with anotification layer without the necessity of receiving an acknowledgementtypically required in a REQUEST-RESPONSE exchange. For example, thestore and forward logic 210 may send a payload including a flag showingthat content GGG was modified. Command GGG may represent an email flagused to indicate that an email has changed from an unread state to aread state. The payload may also contain an indicator used to identifythe particular email. Once the notification signal is received, thecommunication between the device gateway 264, the protocol adapter 268and the store and forward logic 210 operate as described above withreference to FIG. 15B. Eventually, the device gateway 264 sends anotification including the command to the user device 310.

FIGS. 16A to 16D illustrate sequence diagrams showing signaling betweena user account 320 and store and forward logic 210 according toembodiments of the present invention.

FIG. 16A shows a sequence when a content router 200 receives (gets)commands from a user account 320. A server gateway 266 may periodicallypoll the user account 320 with a single REQUEST-RESPONSE exchange. Ifnot changes exist, the user account 320 may send a RESPONSE indicatedsuch. If a change exists, the user account 320 may send a RESPONSEindicated the change (not shown). Alternatively, some user accounts 320may initiate a REQUEST-RESPONSE exchange to indicate that a changeexists. The server gateway 266 acknowledges that the REQUEST wasreceived with a RESPONSE including an acknowledgement. In either case,once the server gateway 266 knows that one or more changes exists, theserver gateway 266 sends a REQUEST requesting the changes. The useraccount replies in a RESPONSE with a payload containing a list commands.

The server gateway 266 translates from the server protocol to the commoninternally used protocol, and then sends to the protocol adapter 268 aREQUEST indicating a put of the commands indicated in the payload.Alternatively, if the user account 320 was enabled to communicate usingthe common protocol, the server gateway 266 may be bypassed.

The protocol adapter 268 converts the payload of the REQUEST to asequence of commands (e.g., add, delete and update) and provides thecommands to the store and forward logic 210. The store and forward logic210 processes each command. The store and forward logic 210 may assign amonotonically increasing primary key (e.g., 0030021, 0030022 and0030023) to each command. Furthermore for each command, the store andforward logic 210 may determine a database ID, which may uniquelyidentify a user, a particular content node, and a content type. Thestore and forward logic 210 may also set the queue ID for each commandto indicate that the command is in an incoming queue state. The storeand forward logic 210 may perform a conflict check against each of thecommands associated with the same database ID. If no conflicts aredetected, the commands may be stored in the database with the assignedattributes. If a conflict is detected, the store and forward logic 210resolves the conflict by removing a command existing in the database,discarding the incoming conflicting command, and/or aggregating theincoming command and the existing command.

In response to successful processing and entry into the incoming queue,the store and forward logic 210 returns an indication of the success tothe protocol adapter 268. The protocol adapter 268 in turn responds tothe REQUEST from the server gateway 266 with a RESPONSE of success. Ifany REQUEST-RESPONSE exchange fails, previous REQUEST-RESPONSE exchangewill not need to be repeated. In some embodiments, the server gateway266 exchanges a REQUEST-RESPONSE pair (not shown) with the user account320 to inform the user account 320 that it may discard the previouslycommunicated commands.

FIG. 16B shows a sequence when a content router 200 pushes (puts)commands to a user account 320. When store and forward logic 210 hascommands in its outgoing queue for a user account 320, it may send anotification signal to the server gateway 266. In some embodiments, thenotification signal includes a content type. The server gateway 266captures the notifications and models a client when sending a REQUEST toget pending outgoing commands. In modeling a client, the server gateway266 initiates request on behave of the user account for the outgoingcommands. The protocol adapter 268 performs a get-commands call to thestore and forward logic 210, which returns with a payload of commands.For example, the payload of commands may include adding a new email DDD,deleting a contact EEE, and modifying a title of multimedia content FFF.The protocol adapter 268 may assign an index to each command andincludes the commands in a RESPONSE to the previously received REQUEST.The server gateway 266 then models a client and initiates a REQUEST toput commands to the user account 320. The user account 320 acknowledgesreceipt of the REQUEST and commands with a RESPONSE. The server gateway266 then initiates a REQUEST to acknowledge receipt of the commands bythe user account 320. The protocol adapter converts the acknowledgementinto a remove commands call to the store and forward logic 210 to removecommands from the in-transits queue. The store and forward logic 210returns a success, and the protocol adapter 268 acknowledges theRESPONSE received from the server gateway 266 with a RESPONSE.

FIG. 16C shows a sequence of events when a server gateway 266 pushes acommand in a notification message to a user account 320. In someembodiments, the store and forward logic 210 may include a low priorityand/or relatively small payload with a notification. For example, thefact that an email has been read may be considered a low priority andsmall byte sized event. Such low priority events may be communicatedwith the notification layer without the necessity of receiving anacknowledgement typically required in a REQUEST-RESPONSE exchange. Insome embodiments, the notification signal includes a content type. Inresponse to receiving the initial notification signal, the servergateway 266 may model a client when sending a REQUEST to get pendingoutgoing commands. In response, the protocol adapter 268 performs aget-commands call to the store and forward logic 210, which returns witha command. For example, the command GGG may include an instruction tomodifying a read state of an email. The protocol adapter 268 may assignan index to the command and includes the command in a RESPONSE to thepreviously received REQUEST. The server gateway 266 then pushes thecommand in a notification signal to the user account 320. Either beforeor after sending of the notification signal, the server gateway 266 mayinitiates a REQUEST to acknowledge receipt of the commands by the useraccount 320. The protocol adapter converts the acknowledgement into aremove command call to the store and forward logic 210 to remove thecommand from the in-transits queue. The store and forward logic 210returns a success, and the protocol adapter 268 acknowledges theRESPONSE received from the server gateway 266 with a RESPONSE.

FIG. 16D shows an embodiment of the present invention with a servergateway 266 positioned behind a firewall along with an account serverhaving a user account 320. If the server gateway 266 is behind afirewall, the protocol adapter 268 may be unable to initiate aREQUEST-RESPONSE exchange and a notification from the protocol adapter268 would be blocked. In this case, the server gateway 266 may initiateeach REQUEST-RESPONSE exchange.

Instead of receiving notifications to determine that the content router200 has commands in its outgoing queue 241, the server gateway 266 mayrequest the notification information by initiating a REQUEST-RESPONSEexchange. The server gateway 266 may periodically poll for commands inthe outgoing queue 241 by sending the protocol adapter 268 a REQUESTindicating a poll for outgoing commands is requested. In response, theprotocol adapter 268 calls the store and forward logic 210 to check forany outgoing commands for the user account 320. The store and forwardlogic 210 returns an indication of whether or not any commands exist inthe outgoing queue 241. The protocol adapter 268 may respond to theprevious REQUEST with a RESPONSE including the returned indication ofwhether or not any commands exist in the outgoing queue 241. If acommand exists in the outgoing queue 241, the server gateway 266 mayinitiate a REQUEST to get the outgoing commands as shown in FIG. 16B(with a REQUEST-RESPONSE exchange) or as shown in FIG. 16C (within anotification signal). Additionally, the server gateway 266 may poll theuser account 320 for changes if the user account 320 communicatescommands to the server gateway 266, the server gateway 266 may initiatea REQUEST to put the commands to the incoming queue 231 as shown in FIG.15A.

While the invention has been described in terms of particularembodiments and illustrative figures, those of ordinary skill in the artwill recognize that the invention is not limited to the embodiments orfigures described.

It will be appreciated that the above description for clarity hasdescribed embodiments of the invention with reference to differentfunctional units. However, it will be apparent that any suitabledistribution of functionality between different functional units may beused without detracting from the invention. Hence, references tospecific functional units are only to be seen as references to suitablemeans for providing the described functionality rather than indicativeof a strict logical or physical structure or organization.

The invention can be implemented in any suitable form includinghardware, software, firmware or any combination of these. Differentaspects of the invention may be implemented at least partly as computersoftware or firmware running on one or more data processors and/ordigital signal processors. The invention may be implemented in acomputer program product such as a machine readable medium (e.g., amemory card, ROM, RAM, PROM, EPROM, flash memory, magnetic or opticaldiskette, CD-ROM, DVD, and the like). The elements and components of anembodiment of the invention may be physically, functionally andlogically implemented in any suitable way. Indeed, the functionality maybe implemented in a single unit, in a plurality of units or as part ofother functional units. As such, the invention may be implemented in asingle unit or may be physically and functionally distributed betweendifferent units and processors.

Although the present invention has been described in connection withsome embodiments, it is not intended to be limited to the specific formset forth herein. Rather, the scope of the present invention is limitedonly by the claims. Additionally, although a feature may appear to bedescribed in connection with a particular embodiment, one skilled in theart would recognize that various features of the described embodimentsmay be combined in accordance with the invention. Moreover, aspects ofthe invention describe in connection with an embodiment may stand aloneas an invention.

Moreover, it will be appreciated that various modifications andalterations may be made by those skilled in the art without departingfrom the spirit and scope of the invention. The invention is not to belimited by the foregoing illustrative details, but is to be definedaccording to the claims.

1. A content routing system for routing changes to information between aplurality of content nodes, the content routing system comprising: storeand forward logic comprising logic for: selecting a set of destinationcontent nodes based on a content type of an incoming command and one ormore routing parameters; modifying the incoming command with datamodulation logic operable to generate at least one outgoing command,wherein each outgoing command corresponds to a selected content node;and a connected data set configuration, coupled to the processing logic,for holding the one or more routing parameters.
 2. The content routingsystem of claim 1, wherein the data modulation logic comprises at leastone data module for modifying at least one data field of the incomingdata field.
 3. The content routing system of claim 1, wherein theincoming command comprises an XML-tree data structure schema.
 4. Thecontent routing system of claim 3, wherein the data modulation logic isoperable to modify a particular node of the XML-tree data structure. 5.The content routing system of claim 1, wherein the data modulation logicis operable to divide a first incoming command associated with a firstcontent entry into multiple outgoing commands associated with secondmultiple content entries.
 6. The content routing system of claim 5,wherein the data modulation logic is operable to maintain integritybetween the first content entry and the second multiple content entries.7. The content routing system of claim 1, wherein the data modulationlogic is operable to merge multiple first incoming commands associatedwith first content entries into a smaller number of second commandsassociated with second content entries.
 8. The content routing system ofclaim 7, wherein the data modulation logic is operable to maintainintegrity between the first content entries and the second contententries.
 9. The content routing system of claim 1, further comprisingdata consolidation logic operable to identify potential duplicatecontent entries based on comparing a hash-value of the incoming commandto a list of hash-values.
 10. The content routing system of claim 9,wherein the list of hash-values is generated from content associatedwith at least one content node.
 11. The content routing system of claim9, wherein the hash-value is determined from less than all content ofthe incoming command.
 12. The content routing system of claim 9, whereinthe hash-value is determined from at least one predefined significantproperty of the incoming command.
 13. A method of routing changes toinformation between a plurality of content nodes and a command memory,the method comprising, at a content router: receiving an incomingcommand from a first content node; storing the incoming command in acommand memory; selecting a set of destination content nodes based on acontent type of the incoming command and a routing parameter associatedwith the destination content node and the content type; modulating theincoming command based on capabilities of the destination content node,wherein the modulating comprises modifying at least one data field ofthe incoming command to generate of an outgoing command.
 14. The methodof claim 13, wherein the incoming command comprises an XML-tree datastructure schema.
 15. The method of claim 14, wherein the fieldcomprises a particular node of the XML-tree data structure.
 16. Themethod of claim 13, further comprising dividing a first incoming commandassociated with a first content entry into multiple outgoing commandsassociated with second multiple content entries.
 17. The method of claim16, wherein integrity is maintained between the first content entry andthe second multiple content entries.
 18. The method of claim 13, furthercomprising merging multiple first incoming commands associated withfirst content entries into a smaller number of second commandsassociated with second content entries.
 19. The method of claim 18,wherein integrity is maintained between the first content entries andthe second content entries.
 20. The method of claim 13, furthercomprising identifying potential duplicate content entries based oncomparing a hash-value of the incoming command to a list of hash-values.21. The method of claim 20, wherein the list of hash-values is generatedfrom content associated with at least one content node.
 22. The methodof claim 20, wherein the hash-value is determined from less than allcontent of the incoming command.
 23. The method of claim 20, wherein thehash-value is determined from at least one predefined significantproperty of the incoming command.
 24. A computer program productcomprising program code for use in a content routing system comprisingprocessing logic and a command memory, the content routing system forrouting changes to information between a plurality of content nodes andthe command memory, the computer program product comprising: programcode for receiving an incoming command from a first content node;program code for selecting a set of destination content nodes based on acontent type of the incoming command and a routing parameter associatedwith the destination content node and the content type; program code formodifying the incoming command to generate at least one outgoingcommand, wherein each outgoing command corresponds to a selected contentnode.
 25. The computer program product of claim 24, further comprisingprogram code for at least one data module for modifying at least onedata field of the incoming command.
 26. The computer program product ofclaim 25, wherein the incoming command comprises an XML-tree datastructure schema.
 27. The computer program product of claim 26, whereinthe data modulation logic is operable to modify a particular node of theXML-tree data structure.
 28. The computer program product of claim 24,wherein program code for modifying is operable to divide a firstincoming command associated with a first content entry into multipleoutgoing commands associated with second multiple content entries. 29.The computer program product of claim 28, wherein integrity ismaintained between the first content entry and the second multiplecontent entries.
 30. The computer program product of claim 24, whereinthe program code for modifying is operable to merge multiple firstincoming commands associated with first content entries into arelatively smaller number of second commands associated with secondcontent entries.
 31. The computer program product of claim 30, whereinintegrity is maintained between the first content entries and the secondcontent entries.
 32. The computer program product of claim 24, furthercomprising data consolidation logic operable to identify potentialduplicate content entries based on comparing a hash-value of theincoming command to a list of hash-values.
 33. The computer programproduct of claim 32, wherein the list of hash-values is generated fromcontent associated with at least one content node.
 34. The computerprogram product of claim 32, wherein the hash-value is determined fromless than all of the incoming command.
 35. The computer program productof claim 32, where the hash-value is determined from at least onepredefined significant property of the incoming command.